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.