11:59 a.m.
I haven't reviewed the JPA spec changes but don't entity listeners fire on
instantiation or association and not during instrumentation? If so then it seems like
there shouldn't be a problem?
The new rules say that CDI, by default, scans only classes which have been annotated as
having a scope or an EE component that has a scope. So at least entities would normally be
excluded. If someone does set an attribute in beans.xml to scan all resources then it
definitely would attempt to load them. At some point we should update Weld to do more up
front scanning before loading (it might already do some of that). Although I don't
think this is the solution, it's just something I felt like noting.
On Jun 7, 2013, at 11:19 AM, Scott Marlow <smarlow(a)redhat.com> wrote:
For application deployments that use ClassFileTransformer to
enhance/rewrite entity classes, we start the persistence unit service
(PersistenceProvider.createContainerEntityManagerFactory()) during the
Phase.FIRST_MODULE_USE (before any application classes have been loaded).
For application deployments that have an explicit CDI Bean Manager,
there is a beans.xml that means the ClassFileTransformer will not work,
since the CDI Bean Manager will scan all of the application classes
(loading them), before the persistence unit service is started (so that
the persistence provider can use CDI in entity listeners).
The same is also true for implicit CDI Bean manager support [1], expect
all application deployments that contain an ejb3 module, will be wired
for CDI (meaning JPA ClassFileTransformer support will work even less).
I raised this on the JPA 2.1 EG [2] in response to an earlier
discussion, about switching to a two phase approach to address problems
like this (didn't discuss CDI implicit support then but am raising that
now).
[3] talks about why we don't create the CDI bean managers before the
Install phase (would cause all application classes to be read which
breaks JPA ClassFileTransformer use).
[4] is for adding implicit CDI support but is blocked currently by [5].
We can add persistence unit flags (jboss.as.jpa.classtransformer=false)
for disabling JPA ClassFileTransformer support as a workaround but that
doesn't help enough since many deployments will have implicit CDI
support enabled (since they contain EJB modules). We could add a way to
disable implicit CDI support as another workaround for deployments that
want to use ClassFileTransformer.
I'm not yet seeing a proper fix for this. Anyone else?
Scott
[1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive
[2]
https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/m...
[3] https://issues.jboss.org/browse/WFLY-1322
[4] https://issues.jboss.org/browse/WFLY-476
[5] https://issues.jboss.org/browse/WFLY-1463
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev