Java Platform, Enterprise Edition (Java EE) 5 brought dependency injection (DI) with Convention over Configuration to Enterprise JavaBeans (EJB) 3.0. Java EE 6 introduces the flexible and powerful @Inject dependency injection model (JSR-330 and JSR-299) in addition to the already existing @EJB annotation. So when should you use what?
Find out in this new tech article, "Contexts and Dependency Injection in Java EE." Brought to you by the Oracle Technology Network.
It depends on what you need: if you need all the services delivered by an EJB object, or you simply need of a simple injection.
For example EJBs offer pooling and db transaction, while CDI not.
See this post:
?http://stackoverflow.com/questions/4684112/how-do-cdi-and-ejb-compare-interact
Not sure if It is clear to me, but..
Suppose I have a non web app. For example, a swing accessing an EJB as following.
Swing --remotinlgy acessing--> EJB [email protected]> DAO
In this case, I don't have HTTPSession and neither HTTPRequest. So, how do CDI manage @RequestScoped, @SessionScopedand @ConversationScoped in this context?
Thanks
A well-behaved CDI implementation should throw an exception letting you know that the HTTP specific contexts cannot be created.
So.. if I don't have a web container, @Inject annotation works partially. In other words, it is not possible to use the new stuff if your have a service only container..
Great, another big issue in spec.
So.. if I don't have a web container, @Inject annotation works partially. In other words, it is not possible to use the new stuff if your have a service only container..
Great, another big issue in spec.
The JSR-299 specs are fairly clear on the subject. I specifies that an active context has to be present for invocations on beans using any of the built-in scopes (request, session, application, conversation) to be possible, or a ContextNotActiveException should be thrown. It doesn't require that all built-in scopes are available ALWAYS, only what should happen when they are not. Like Reza said, it's up to the well-behaved (and compliant) container to ensure this contract is fullfilled. It's up to you as a developer/architect to not design a system that relies on session-scoped dependencies in a system that doesn't have sessions. Kind of like trying to call HttpSession.getAttribute in an application that isn't a web application.
Then, of course, it depends on what you define a "service only" container as. If you are talking a "standard" web service application, that is of course a servlet application at the bottom so as long as you deploy and run it in a JEE6 compliant application server, you will have full access to request and sessions scopes during service invocations (on the server, that is).
This is pretty much analogous to how Spring handles request and session scoped beans. They can be used when the scopes exist, but you have to be aware of the running context when you design your application.
CDI 1.1 is slated for Java EE 7. If you believe the request, session and conversation scopes should be independent of HTTP, feel free to propose such a change to the spec lead/expert group. I personally don't see the need since most web services that I've seen in the real world are stateless in nature.
