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

[Scott Marlow]

On 06/08/2013 11:48 PM, 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.

Currently, Hibernate is using the BM during deploy.  I think that 
Hibernate would need to defer using CDI to call PostConstruct/PreDestroy 
on the entity listener class until runtime (deployment would be 
complete).  I'm not sure of the performance changes of that change but 
since your recommending it, I assume we could use CDI at runtime just as 
well?

>
> 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
>
>