<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">A JPA impl is likely to use the BM
proxy at bootstrap to inject entity listener. Since there is no
other bootstrap phase when this could be performed (other than
during EMF creation), the other option is to inject entity
listeners lazily at runtime by which we would lose the chance to
validate entity listener injection points at bootstrap. Even if we
change Hibernate to inject entity listeners lazily, we'll probably
have the same problem with other JPA providers should we want to
support them.<br>
<br>
On 06/09/2013 05:48 AM, Stuart Douglas wrote:<br>
</div>
<blockquote
cite="mid:CAAoo=c5sZYt=Nr=snnmF9v8w2pSq-962gAWuV9PYx5Ts-78=tQ@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://issues.jboss.org/browse/WFLY-1322"
target="_blank">https://issues.jboss.org/browse/WFLY-1322</a><br>
[4] <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/WFLY-476"
target="_blank">https://issues.jboss.org/browse/WFLY-476</a><br>
[5] <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>