<div dir="ltr">I think the only real way to solve this is to pass in a BM proxy to JPA, that delegates to the real BM once it becomes available. As long as JPA does not attempt to use the BM during startup this should be fine.<div>
<br></div><div style>Stuart</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 8, 2013 at 2:20 AM, Scott Marlow <span dir="ltr"><<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For application deployments that use ClassFileTransformer to<br>
enhance/rewrite entity classes, we start the persistence unit service<br>
(PersistenceProvider.createContainerEntityManagerFactory()) during the<br>
Phase.FIRST_MODULE_USE (before any application classes have been loaded).<br>
<br>
For application deployments that have an explicit CDI Bean Manager,<br>
there is a beans.xml that means the ClassFileTransformer will not work,<br>
since the CDI Bean Manager will scan all of the application classes<br>
(loading them), before the persistence unit service is started (so that<br>
the persistence provider can use CDI in entity listeners).<br>
<br>
The same is also true for implicit CDI Bean manager support [1], expect<br>
all application deployments that contain an ejb3 module, will be wired<br>
for CDI (meaning JPA ClassFileTransformer support will work even less).<br>
<br>
I raised this on the JPA 2.1 EG [2] in response to an earlier<br>
discussion, about switching to a two phase approach to address problems<br>
like this (didn't discuss CDI implicit support then but am raising that<br>
now).<br>
<br>
[3] talks about why we don't create the CDI bean managers before the<br>
Install phase (would cause all application classes to be read which<br>
breaks JPA ClassFileTransformer use).<br>
<br>
[4] is for adding implicit CDI support but is blocked currently by [5].<br>
<br>
We can add persistence unit flags (jboss.as.jpa.classtransformer=false)<br>
for disabling JPA ClassFileTransformer support as a workaround but that<br>
doesn't help enough since many deployments will have implicit CDI<br>
support enabled (since they contain EJB modules). We could add a way to<br>
disable implicit CDI support as another workaround for deployments that<br>
want to use ClassFileTransformer.<br>
<br>
I'm not yet seeing a proper fix for this. Anyone else?<br>
<br>
Scott<br>
<br>
[1] <a href="http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive" target="_blank">http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive</a><br>
[2]<br>
<a href="https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/message/0" target="_blank">https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/message/0</a><br>
[3] <a href="https://issues.jboss.org/browse/WFLY-1322" target="_blank">https://issues.jboss.org/browse/WFLY-1322</a><br>
[4] <a href="https://issues.jboss.org/browse/WFLY-476" target="_blank">https://issues.jboss.org/browse/WFLY-476</a><br>
[5] <a href="https://issues.jboss.org/browse/WFLY-1463" target="_blank">https://issues.jboss.org/browse/WFLY-1463</a><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div><br></div>