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

[Emmanuel Bernard]

If we don't do that we should :)
The slightly sad thing is thy conceptually it makes sense for CDI to start before JPA. 

On 8 juin 2013, at 23:48, Stuart Douglas <stuart.w.douglas at gmail.com> 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> 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
>> 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/20130609/8bc6e6ce/attachment.html