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

[Steve Ebersole]

As Scott stated, Hibernate is doing the CDI calls as part of the 
EntityManagerFactory bootstrap (however that translates to WildFly 
deployment phases...).  There is a difficulty with delaying these CDI 
calls.  Getting around that would require either:
1) a 2-phase bootstrap process for the EntityManagerFactory.  Even 
though that proposal was not accepted into the JPA spec, I went ahead 
and broke out Hibernate's bootstrapping into a 2-phase process, so 
WildFly (via jipijapa) could leverage that.
2) Creating proxies of the listeners that delegate to the real listeners 
and perform the init on first call.  Ugh.  Proxies calling proxies 
calling proxies... not a recipe for great performance.  Not to mention 
don't call me to debug through that mess

There is a third option.  How entity listeners are built is hidden 
behind an interface (called ListenerFactory oddly enough).  I can expose 
that as an integration point for WildFly to be able to plug in whatever 
"delayed init" scheme it deems appropriate.  The only reason I'd suggest 
this is if y'all feel strongly about option 2 above (I'm not comfortable 
implementing that in the Hibernate code base).  But my vote would be for 
the first option.

I am open to other suggestions.


On 06/10/2013 02:10 AM, Jozef Hartinger wrote:
> Weld can be started before a JPA impl without a risk of suppressing
> ClassFileTransformers under condition that all entities are annotated
> with @Vetoed. We could document that as a requirement.
>
> On 06/07/2013 06:20 PM, Scott Marlow 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