[wildfly-dev] duel between JPA use of ClassFileTransformer and CDI implicit/explicit Bean Manager (why can't we just get along)...

[Jozef Hartinger]

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.

On 06/09/2013 05:48 AM, Stuart Douglas wrote:
> 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.
>
> Stuart
>
>
> On Sat, Jun 8, 2013 at 2:20 AM, Scott Marlow <smarlow at redhat.com 
> <mailto:smarlow at 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/message/0
>     [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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130610/e6643ad1/attachment.html