I started persistence coding and I came across annotations such as #Transactional and #TransactionAttribute. I understand the basic functionality of these two annotations and also that they can be used at both class level and at the method level. What I would like to understand better is the difference between these two annotations. Any help would be appreciated. Thanks.
#TransactionAttribute is for EJB3 beans.
#Transactional is for POJOs (for example Seam, Spring/Hibernate).
#TransactionAttribute is meant for EJB beans.
#Transactional is meant for CDI beans.
No, #Transactional should not be used for annotating EJB business methods. While Java Docs suggests, it may be used for EJB, the EJB specs suggests it should not be used for EJBs at present.
Related
So, pretty straightforward question. Can I mix JEE annotations with Spring annotations on the same project? Are there any known issues with mixing both types of annotations?
For example, #Autowired and #Inject? #Named and #Qualifier?
Should Spring be able to solve injections without issues?
The reason I'm asking this is because I've encountered myself with some legacy code that uses Spring as CDI framework but 60% of the code uses JEE annotations. Some beans, however, are wired using #Autowired, there are also Spring ConfigProperties, etc.
I've already seen some weird behaviour, like classes not being injected, or #Named not being recognized by Spring, etc.
Spring does support CDI annotations, including #Inject, #Named, #Qualifier, ... But it comes with some limitations.
If some class is not injected, or #Named is not recognized, I think it is likely a configuration problem.
I am wondering how can I use the Instance in JUnit4 with Spring
#Inject
Instance<IMyInterface> interfaces;
If I use
#Inject
List<IMyInterface> interfaces;
It works in Spring but not with CDI.
Also, we can use Provider with both CDI and Spring but it's not Iterable.
The #Inject annotation comes from JSR-330-Dependency Injection for Java. Spring knows this annotation and briefly said, Spring treats it as an alternative to #Autowired. That's it.
However, the Instance is part of JSR 299 - Contexts & Dependency Injection. You can have a look at the definition in CDI specifications.
Spring DI is absolutely different and does not implement JSR-299 (CDI) or any other standard. It does not even have a separate API and implementations and everything is just glued together. Therefore, injecting an Instace is not possible with Spring.
In Spring you can't simply call #Transactional method from the same instance, because of AOP-proxy thing. Would it be nice idea to make a self injection and call that method from self proxy instance? Do you see any drawbacks?
It is totally ok.
Moreover there was a Jira ticket for supporting this feature using #Autowired annotations. It's fixed in Spring 4.3+ versions. However for xml-based configuration or using #Resource annotation it's working in the earlier versions.
You can see the discussion bellow this ticket. #Transactional is one of the use case for this:
Particularly interested in #Async and #Transactional use cases.
There is lot of information about Stateless, Stateful and Sigleton beans everywhere but almost nothing about javax.annotation.ManagedBean. At a first look I assumed that It's be similar to Spring's #Component but I can't use it without complete information.
If I annotate a class with #javax.annotation.ManagedBean will it be singleton or it will have instance pool like stateless?
Will the methods inside such class be concurrent? I should make sure as in a singleton they are synchronized by default.
I was thinking of annotating my DAO class with this but the #javax.enterprise.context.*; scopes put me doubt. I think #Stateless will be better. Any comments?
If not on DAO or service classes, where does this annotation fit in?
This answer gives very good explanation but doesn't answer the above questions.
Neither. They are per lookup/injection instances, more like stateful.
No, there is no container-managed concurrency.
(and 4.) Do you need transaction, security, or other EJB capabilities? Then #Stateless is probably better. Otherwise, I would just use CDI since it is better than the #javax.annotation.ManagedBean annotation in nearly all ways, and it is enabled by default in EE 7, so it is clearly the forward direction for EE.
As a bit of background, the #javax.annotation.ManagedBean annotation was added late in the development of the EE 6 cycle, and it is not widely used. The managed bean spec was intended to unify the lifecycle, injection, and naming behaviors of the EJB, CDI, and JSF managed bean component models. That was useful, but in my opinion, the #javax.annotation.ManagedBean annotation was just an afterthought to allow developers to access the minimal component model functionality without the overhead/complexity (real or perceived) of the other component models (EJB necessarily has a fixed set of required services and associated overhead, CDI is better in nearly all ways but is clearly more complex, and JSF managed beans are tied to WAR). However, this "common denominator" is then a quite limited component model with just #PostConstruct, #Resource (and other EE injection), and #Interceptors. There's no security, transaction, scoping/lifecycle (as in EJB or CDI), #PreDestroy, tight integration with the web tier, etc.
Can someone outline the steps required to get hibernate working with spring mvc.
I've seen EntityDao's that basically inherit from a GenericDAo.
The generic Dao has basic operations like GetAll, GetByID, Save, Delete, etc.
And inside their methods they use:
getHibernateTemplate
So basically the Session has to be wired up in a bean, and mysql settings have to be set.
I find the spring documentation to be a little confusing: http://static.springsource.org/spring/docs/3.0.0.RELEASE/spring-framework-reference/html/orm.html#orm-hibernate
The basic components are:
Something to configure and create the Hibernate SessionFactory. This is typically done by the LocalSessionFactoryBean, as used in the example in the link you posted. This exposes a Spring-managed bean that implements the Hibernate SessionFactory interface.
Typically, you then have one or more DAO beans which are injected with the SessionFactory. In many cases, the simplest thing to do here is to extend the convenient HibernateDaoSupport class, which has a sessionFactory property. HibernateDaoSupport proves a getHibernateTemplate() method, which gets a Hibernate Session from the SessionFactory and wraps it in a HibernateTemplate object, which provides various convenience methods for doing common Hibernate operations, and is generally more useful than the raw Session interface.
Using this pattern, there is very little direct interaction between application code and the Hibernate API itself, its mostly done though s Spring intermediate layer. Some would call this a good thing, others would rather Spring stayed out of the way. This is a perfectly good alternative - there's nothing to stop you injecting your bean with SessionFactory and using the Hibernate API directly. The HibernateDaoSupport and HibernateTemplate classes are there purely as a convenience.
There is another way. If you don't want to use HibernateDaoSupport then you could directly inject SessionFactory into your DAO classes. This avoids tying you down to Spring classes.
Refer this for example - Spring Doc
This shows how to use Hibernate APIs directly.
Hope that helps.