I want to log every incoming EJB call into DB.EJB 3 provides #AroundInvoke to intercept the incoming call and outgoing.
Do we have similar thing for EJB 2.x?
Need suggestion how can i achieve it?
Thank you
It depends what you mean by "EJB 2.x".
If you mean an EJB module without an ejb-jar.xml deployment descriptor or with ejb-jar.xml deployment descriptor declared that declares version="3.0" (or higher) but using EJB 2.x-style component interfaces, then yes, interceptors can be applied to any EJB regardless of the interface type they use.
If you mean an EJB module with ejb-jar.xml deployment descriptor that declares version="2.1" (or lower), then no, there is no way to specify an interceptor in such a module. However, if you are running a modern application server with support for at least EJB 3.0, you should be able to just adjust the ejb-jar.xml deployment descriptor to be version 3.0 (or higher). The EJBs should continue to run as-is, but you should then be able to declare interceptors.
Related
I need to declare a Spring bean using Annotation-based config, which will be available throughout the runtime of the Application Server (in my case, JBoss). I should be able to write and read the data to/from the bean across multiple requests. I have read about the global session scoped bean, but couldn't find any concrete examples. Is there a way to implement this and what are the thread-safety concerns with this kind of bean?
Best Regards,
Chandra.
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 know from experience that injection of circular dependencies in EJB do work, at least in some application servers.
I've done it multiple times with self-injection (e.g. to get an EJB proxy for #TransactionAttribute, #RolesAllowed, #Asynchronous etc. to work).
I've done it with more complex graphs too (A->B->A etc.), which obviously work too.
I've done it at least in Glassfish 3/4, Weblogic, and JBoss 7.3. Maybe Weblogic, not sure.
Now, I've been trying to find some precise guarantee from the specification, without success. There are provisions for this in CDI, but I couldn't find any explanation on why it works for EJBs. Is there some indirect one, maybe?
I'm looking from some references from EJB specifications regarding this.
I don't believe the EJB specification explicitly disallows self-injection, which means it implicitly allows it since there is no reason for the bean's own interface to be different from the interface of some other EJB. In practice, self-injection can only work for stateless (and singleton in EJB 3.1) and not stateful since each lookup/injection of a stateful bean creates a new instance, which would result in infinite recusion. For stateful, you can inject SessionContext and use the getter methods to return a "self-proxy" rather than using injection. This technique also works for stateless/singleton, and it might be marginally faster than using injection (particularly if you cache the result in an instance field the same as injection) since the EJB container can probably return a self-proxy more directly than going through injection/JNDI.
The only additional authority I can give to this answer is that I was one of the primary developers/maintainers of the EJB container in WebSphere Application Server for 5 years. To add to your list of products, I know that self-injection also works in practice on WebSphere Application Server.
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.
We all know that in the web tier there is the possibility that only a single instance of a given Servlet exists which services multiple requests. This can lead to threading issues in instance variables.
My question is, is it safe to inject an EJB using the #EJB annotation into a servlet as an instance variable?
My initial instinct would be no, under the assumption that the same instance of the EJB would service multiple requests at the same time. It would seem that this would also be the instinct of a number of other programmers: Don't inject to servlets
However have I jumped to the wrong conclusion. Clearly what is injected into the servlet is a proxy, under the hood does the container actually service each request with a different instance and maintain thread safety? As this forum would suggest: Do inject to servlets
There seems to be a lot of conflicting opinions. WHICH IS CORRECT???
It is safe to inject an EJB in a Servlet as a Servlet instance variable, as long as the EJB is Stateless. You MUST NEVER inject a Stateful Bean in a Servlet.
You must implement your EJB stateless in that it doesn't hold any instance variable which itself holds a stateful value (like Persistence Context). If you need to use the persistence context, then you must get an instance of it IN the methods of the EJB. You can do that by having a PersistenceContextFactory as a EJB instance Variable and then you get an instance of the entity manager from the Factory in the method of the EJB.
The PersistenceContextFactory is thread-safe, thus it can be injected in an instance variable.
As long as you comply to the above mentioned rules, it should be thread-safe to inject a Stateless Bean in a Servlet
Your reference "Don't inject to servlets" mentions nothing about ejbs or #ejb annotation. It talks about not thread safe objects such as PersistenceContext.
Per EJB spec you can access ejbs from variety of remote clients including servlets (EJB 3.0 Specification (JSR-220) - Section 3.1). Injecting ejb using #EJB annotation is a method of obtaining EJB interface via dependency injection (section 3.4.1) which is alternative to looking up ejb objects in the JNDI namespace. So there is nothing special about #EJB annotation with respect to EJBs obtained.
So, based on EJB 3.0 Spec, it's a standard practice to obtain ejbs from servlets using #EJB annotation.
It's a mixed bag.
Stateless session beans may be injected and are safe. This is because even if a single instance of a stub is used, access to the methods will be serialized by the container.
I think what inferreddesign says is not true. It doesn't matter if the stateless session bean uses a persistence context. Only one caller will ever access a single bean instance at the same time, so even though the persistence context is not thread safe, the EJB guards against multiple access to it. Think of it as if every session bean method has the synchronized keyword applied to it.
The main problem with injecting an EJB in a Servlet I think is performance. The single stub instance will become a major area of contention when multiple requests are queuing up while waiting for a session bean method to be executed for them.
I think the simple answer is that you aren't guaranteed that it is safe.
The reason for this is that there is nothing explicit in the EJB specification that says EJB home interfaces have to be thread safe. The spec outlines the behaviour of the server side part only. What you will probably find is that the client skeletons are actually thread safe but you would need to look at how they are implemented by the library you are using. The annotation part will just expand into a service locator so that doesn't buy you anything.