I'm currently learning the new Java EE 6 component models and am confused with the latest dependency injection mechanism. So here are my questions:
1) What is the difference between @Inject and @EJB
2) If I have a simple POJO that contains another POJOs (which one of them is the DAO code), what would be the better choice: @Inject or @EJB?
Can I mix @Inject and @EJB?
An example would be:
ClassA implements InterfaceA and has an instance of ClassA_Adaptor
ClassA_Adaptor implements InterfaceAB and has an instance of ClassB
ClassB implements InterfaceB and has an instance of ClassB_Adaptor and an instance DAO_ClassB
ClassB_Adaptor implements InterfaceB and has an instance of ClassC
ClassC implements InterfaceBC and has an instance of WebService_ClassC
DAO_ClassB will use JPA 2.0 (@PersistenceContext)
I'd like to inject all of them including the DAO and the WebService.
3) Is it a bad approach to only use transactional for certain operations but not for all?
As an example: Some methods in DAO_ClassB are your typical query, while other methods are "write" methods. Is it bad to not wrap the "READ" methods with transaction?
To my understanding, the DAO_ClassB can be wrapped with transaction using @EJB (inject the DAO_ClassB and make all methods transactional). How can I control it?
Sorry if some of the questions are confusing because I know only bits and pieces of the Java EE 6 new component model.
@EJB injects EJBs only, but @Inject can be used to inject POJOs rather than EJBs. However, @Inject requires that your archive be a BDA (contain beans.xml for EE 6, or implicitly in EE 7). @Inject also has additional CDI-specific capabilities (scopes, interceptors, etc.), but those capabilities incur extra overhead. Application servers have support for specifying @EJB bindings so that a deployer can choose the target EJB, but @Inject only allows the application developer to choose the target EJB (and it must exist in the application).
If the target is not an EJB, then you must not use @EJB.
It depends whether you're making multiple inter-related queries and then attempting to make business decisions. You need to understand isolation levels and take them into consideration, even for read-only operations.