Marius Bogoevici [
http://community.jboss.org/people/marius.bogoevici] created the
discussion
"Spring + JPA/Hibernate and native Hibernate applications in AS7"
To view the discussion, visit:
http://community.jboss.org/message/610407#610407
--------------------------------------------------------------
Following a discussion with Scott Marlow, I'm trying to summarize the issues
encountered with respect to running Spring and native Hibernate applications in JBoss AS7,
as well as some possible workarounds and solutions discussed via different channels (IRC,
JIRA). The goal is to consolidate all these different topics in a single place.
*Group 1. Issues concerning non-Java EE JPA deployments*
A) If we have a deployment which contains a META-INF/persistence.xml which is not
compatible with the requirement for container-managed persistence units (e.g. using
RESOURCE_LOCAL transactions), the deployment will fail.
In the past, it was possible to suppress the deployment of the persistence unit, by
indicating JBoss to ignore the persistence unit definition file.
The current workaround is to rename the persistence unit definition file, but ideally we
should provide a less invasive fix.
Possible solution(s):
1) Create a mechanism for instructing JBoss to ignore certain files at deployment time - a
prototype exists
2) Create a mechanism for instructing JBoss to disable an entire subsystem at deployment
time (e.g. JPA)
1) is simpler to implement, 2) has the advantage that it provides a more comprehensive
solution (e.g. 1) will not prevent annotation processing, currently, but 2) would)
B) Even if the workaround is applied and the persistence unit is not deployed, JBoss will
scan the existing classes for @PersistenceUnit and @PersistenceContext annotations. This
is necessary for classes which need to be Java EE-injected. However, if these annotations
are defined on classes which are not Java EE-injected and a persistence unit is not found,
the deployment will still fail (no persistence unit found). For example, Spring
applications may use the @PersistenceContext annotation on beans which are not Java
EE-injected.
The current workaround is to avoid the usage of @PersistenceContext in such scenarios.
Again, we should provide a less invasive fix if possible.
Possible solutions:
1) Do not throw a deployment exception when @PersistenceContext is found but no
persistence unit exists. Rather, mark the injection point as invalid and throw a runtime
exception if a class bearing that injection point is put in use as a Java EE component.
Generally speaking a deployment error would be preferrable, but in this case the decision
making process yields false positives.
2) Restrict @PersistenceContext annotation processing to classes which can be identified
as Java EE components - this may be more difficult than expected due to the variety of
scenarios and expensive checking (servlet artifacts, EJB, managed beans)
3) Create a mechanism for instructing JBoss to disable an entire subsystem at deployment
time (e.g. JPA)
*Group 2. Issues affecting all kinds of JPA deployments*
C) A deployment exception is currently thrown if @PersistenceContext and @PersistenceUnit
annotations are found on methods which are not setters.
While the Java EE specification indicates that only setter methods (besides fields) of
container-managed objets are injection targets, for other frameworks (e.g. Spring) it is
possible to extend injection support to other methods as well, on objects which are not
container managed.
Possible solutions:
1) Ignore non-setter methods, the specification does not require an exception to be thrown
in this case
*Group 3. Issues affecting native Hibernate applications*
D) Hibernate 3 was previously available on the CP. Applications migrating from older
versions of JBoss AS will need to include a dependency on the org.hibernate module.
However, due to API changes in Hibernate, some Hibernate 3 applications may not be able to
work with Hibernate 4 (e.g. Spring 3 apps using LocalSessionFactoryBean). *
*
A possible workaround is to include Hibernate 3 in the deployment unit.
Possible solutions:
1) Provide an optional org.hibernate:3 module that those application can depend on.
E) Decide when to include the Hibernate module and when not (affects hybrid EE/native
Hibernate JPA applications)
... I will let Scott detail that use case.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/610407#610407]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]