[
https://issues.jboss.org/browse/AS7-946?page=com.atlassian.jira.plugin.sy...
]
Scott Marlow commented on AS7-946:
----------------------------------
One other idea, to catch hybrid applications (that use EE JPA and Hibernate JPA), would be
to check for the presence of Hibernate jars in the app. A variation of this (not
currently activated) is in PersistenceProviderProcessor.
In a later release, perhaps 7.1, I would like to use PersistenceProviderProcessor to
detect top level deployments that are persistence providers. Perhaps if the deployment is
not a top level deployment, PersistenceProviderProcessor could mark it as a contained
persistence provider. If the contained persistence provider conflicts with the TLD, we
could know that we should avoid most (if not all) EE JPA deployment activities for that
application.
Or we could try avoiding being so smart about what the application needs and support a
simple way for the needs to be expressed in plain text :-) This is more likely to cure
our current over restrictiveness (IMO).
Persistence annotation processing is overly restrictive
---------------------------------------------------------
Key: AS7-946
URL:
https://issues.jboss.org/browse/AS7-946
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: No Release
Reporter: Marius Bogoevici
Assignee: jaikiran pai
If a deployment contains classes bearing the @PersistenceContext annotation, the
annotation processor will fail the deployment if a persistence unit is not found. While
this is correct for classes which are a target for container-driven injection, the
application may contain annotated classes that are not injection targets according to the
Java EE specification. This is not illegal according to the specification.
To wit, a Spring application may use @PersistenceContext for performing Spring-driven
injection of Spring-managed entity manager factories.
In the past, such applications could have used the 'metadata-complete' attribute
in web.xml, but this does not seem to work anymore.
Regardless, of that, the server could adopt a more lenient approach, by failing the
injection only when a managed bean is actually injected with a non-existent PU/PC
reference.
The other variant would be to restrict validation to classes which are actual injection
targets according to the Java EE specification.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira