What is a stub in ejb?
Is it a reference variable for Remote Bean class Object in remote JVM or it is a reference variable for Object residing in the same JVM?
Is a reference variable to an Object residing in the same JVM.
The key point is that this object has the ability to communicate with a remote object residing in another JVM.
It's a Proxy that encapsulates the remote method invocation details, which allows you to invoke methods in a remote object as if it was residing in the same JVM.
Related
Context
I am trying to pass a name/value pair during runtime via ASM(Instrumentation) in a remote EJB call.
The client application is a JSP that is deployed on Tomcat 7. I have used the weblogic thin client on the client application (wlthint3client.jar). The EJB server application, a stateless session bean, is deployed on WebLogic 12c.
Passing the name/value pair as a EJB method parameter is not an option since I am profiling the application. Hence the need for ASM/Instrumentation.
JBoss
For JBoss/Wildfly, I was able to figure out that the following class and method could be instrumented to pass the name/value pair.
Classname: org.jboss.ejb.client.EJBClientInvocationContext
Method Name: getContextData()
Based on my research, the getContextData method returns a Map to which I appended my name/value pair. This Map reference is sent to the server side EJB application.
WebLogic/WebSphere
I need an equivalent in WebLogic and WebSphere of the same context data type of an object (i.e equivalent of the above JBoss' class and method name) so that I could pass my name/value pair during runtime via ASM/instrumentation.
If you could kindly point me to some references, would appreciate your help.
Questions about ejb session bean behavior when used as injected bean instances.
I'm not 100% sure how this works. I guess it from practice and from reading documents on the subject.
I want to know how #EJB annotation is processed by container in detail.
Session bean have interfaces, impl class, deployment descriptor. We package them in ejb jar.
What is putted in global JNDI by container? Static references to
business interfaces ?
How and when global JNDI is read from ?
When component JNDI ENC is populated with ejb reference ?
Is this reference in JNDI ENC (java:comp/env/beanB) is reference to
session bean component interface, session bean instance proxy or
session bean instance ? Is there difference for SLSB and SFSB ?
With #EJB annotation on field does every new ejb session bean
instance get new instance of injected ejb in the annotated field or
all ejb instances share the same injected ejb session bean instance
?
Does ejb injection by lookup (on session context) provide always new
injected ejb instance, example: calling ctx.lookup(ejbReference) in
loop ?
In EJB 3.0, the JNDI names are vendor-specific (if available at all; in theory, a container could support EJB references only), but vendors typically return an EJB reference/proxy. In EJB 3.1, the specification requires the EJB container to make specific java:global, java:app, and java:module names available, and the object returned from these lookups must be an EJB reference/proxy.
The global JNDI is accessed when you perform a JNDI lookup. The container might access the global JNDI names in other cases (e.g., when resolving #EJB(lookup="java:app/...")).
It's undefined when the container populates java:, but the contents must be available before lifecycle callback or business methods are invoked on the component instance.
#EJB/<ejb-ref>/<ejb-local-ref> ensure lookups always return an EJB reference/proxy and never an actual bean instance. The proxy ensures that all container services are performed (security, transaction, remoting, etc.) before invoking an actual bean instance. For SLSB, an arbitrary bean instance will be invoked, and the same or different actual instance might be invoked depending on the thread, concurrency, timing, vendor-specific configuration, etc. For SFSB, a bean instance with a specific identity will be invoked; you are likely to get the same bean instance, but you might not if the EJB container has passivated the actual bean instance, but reactivation should result in an instance with equivalent state. For singleton session bean in EJB 3.1, you are guaranteed the singleton bean instance will be invoked.
It's undefined whether you get the same proxy instance. For SLSB and singleton beans, injection or lookup could return a single proxy that delegates to the actual bean instance as mentioned above. For SFSB, the proxy is basically required to be a separate instance per injection or lookup since the proxy must store some state with the identity so it can invoke the specific actual bean instance.
It's undefined what the container does, but injection is typically implemented by containers using Context.lookup followed by Field.set (or Method.invoke for setter method injection). Regardless, the instance handling is as described above.
I can see that Handle stores the reference to the beans. But how its useful for clients calling this ejb?
What are the things that clients can achieve by getting the Handle to the ejb bean?
In RMI-IIOP, a remote reference (stub) needs to be connected to an ORB instance to be usable. If you serialize and deserialize a stub yourself using ObjectOutputStream/ObjectInputStream to store in a file or database, then the deserialized stub will be disconnected, and attempting to use it will fail. If Handle and HomeHandle are serialized instead of the reference itself, then the EJB spec requires them to use the environment's HandleDelegate, which has a reference to the server's ORB instance, so the remote reference can be reconnected after deserialization.
I was wondering... Let's say that I have two stateless beans in ejb 3.1:
#Stateless
Class1
#EJB MyUniqueInstanceBean uniqueBean1;
2.
#Stateless
Class2
#EJB MyUniqueInstanceBean uniqueBean2;
Are uniqueBean1 and uniqueBean2 guaranteed to be unique instances of MyUniqueInstanceBean?
If MyUniqueInstanceBean is Stateless it is not in your hands are calls to uniquebean1 and uniquebean2 actually calls to same instance. In EJB 3.1 specification this is told with following words:
Because all instances of a stateless session bean are equivalent,
the container can choose to delegate a client-invoked method to any
available instance. This means, for example, that the container may
delegate the requests from the same client within the same transaction
to different instances, and that the container may interleave requests
from multiple transactions to the same instance.
If MyUniqueInstanceBean is Stateful, it is guaranteed that uniquebean1 and uniquebean2 do not refer to same instance. Again from specification:
A session bean instance’s life starts when a client obtains a
reference to a stateful session bean instance through dependency
injection or JNDI lookup, or when the client invokes a create method on the session bean’s home interface. This causes
the container to invoke newInstance on the session bean class to
create a new session bean instance.
If you are using Singleton, then both refer to same instance, because there is only one instance:
A Singleton session bean is a session bean component that is
instantiated once per application. In cases where the container is
distributed over many virtual machines, each application will have one
bean instance of the Singleton for each JVM.
Why do we need an init() method in servlet? Can't we use the constructor to initialization?
Because Servlet is an interface, not an abstract class. Constructor arguments cannot be specified on an interface, so the ServletContext needs to be specified on a normal method signature.
This allows the application server to know how to initialize any Servlet implementation properly.
Another solution would have been to require, but not enforce at compile time, a constructor taking ServletContext. The application server would then call the constructor via reflection. However, the designers of the Servlet specification did not chose this path.