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.
Related
I am doing EJB lookup on application deployed on liberty inside a Listener class (sessionDestroyed method).
I am not starting any new thread. Still getting the below error
javax.naming.NamingException: CWNEN1000E: "A JNDI operation on a java:comp/env name cannot be completed because the current thread is not associated with a Java Enterprise Edition application component. This condition can occur when the JNDI client using the java:comp/env name does not occur on the thread of a server application request. Make sure that a Java EE application does not run JNDI operations on java:comp/env names within static code blocks or in threads created by that application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on java:comp/env names"
Any thoughts/pointers regarding this ?
I’ve tried CDI injection and #EJB injection of Stateless EJBs in a Rivr dialog. They don’t work.
I’ve also tried JNDI lookup of the EJBs through the Global JNDI name but I get following error (note I am using java:global but I get this message):
A JNDI operation on a java:comp/env name cannot be completed because the current thread is not associated with a Java Enterprise Edition application component. This condition can occur when the JNDI client using the java:comp/env name does not occur on the thread of a server application request. Make sure that a Java EE application does not run JNDI operations on java:comp/env names within static code blocks or in threads created by that application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on java:comp/env names.
Is there anyway I can inject or locate CDI #Named or EJBs in a Rivr dialog?
thanks
Ignacio
I examined the Spring example in Rivr cookbook and found that the DialogFactories are executed in the ServletThread. This allowed me to perform a standard JNDI lookup using the Global JNDI name successfully and pass the EJBs to the Dialog being created.
Rivr team confirmed this by email and I am now successfully accessing EJBs that way.
I could not perform standard #Inject or #EJB injections but the JNDI "traditional" solution worked for me.
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.
We are using ejb 2.1 to expose as a webservice using apache axis2.I have read in codebranch website that both are serverside components where in ejb can be run in more than one server unlike servlets..but I didn't get clear picture of difference.
Let me quote this old (but good) comparison.
Enterprise JavaBeans are components meant to encapsulate business logic. They do not handle presentation and have a precise set of restrictions they must obey. An EJB may not manage threads, access files with the java.io package, have a GUI, accept socket connections, or load native libraries. These restrictions are imposed because EJBs execute inside an EJB container, roughly analogous to the way servlets execute in a servlet container. Where servlets can be used to perform many arbitrary tasks, including the generation of HTML pages, EJBs are used almost entirely as business objects. A session bean represents a client for a session or transaction and an entity bean represents a persistent business object that is usually stored in a database. Unlike servlets, a single session bean may exist per client. A single servlet may serve many clients. A session bean usually mediates client access to entity beans, shielding the client from the details of managing state.
I got exact answer Both are server side entities.EJB is designed by wrapping RMI API's.EJB is a service at Enterprise level.Main advantage that EJB can be a webservice which can deployed anywhere in the world.EJB is servicelayer enity which can even used by servlets.
We can have plain java in the service layer but differance that EJB has is it(EJB) can be alone deployed in any server unlike plain-java service layer.
Our flex client needs to invoke server side EJB3 session bean. For each module we have seperate session bean.
Whether it is best to have separate flex end point (remote object) to each session bean to invoke methods or to create a single facade session bean as an endpoint and invoke other session bean methods through this facade bean.
Whether creating multiple flex end points increases the performance or its an expensive process?
Creating a RemoteObject is not an expensive process but having many of them won't really increase client-side performance either. Typically all of your RemoteObjects will reference a shared ChannelSet which basically represents the connection to the server endpoint. I would recommend using one RemoteObject for each session bean you have. You can relate a RemoteObject to a session bean by specifying the "destination" property on the RemoteObject and ensuring that your server side implementation of the FlexFactory interface resolves the destination name to the appropriate session bean.