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

[Jason Greene]

I guess the point I am still not clear on is exactly when the entities are instantiated. My understanding is that the earliest a user can cause a JPA impl load them is inside a PostConstruct method. That is unless JPA providers load instances for some kind of caching purposes?

On Jun 10, 2013, at 12:25 PM, Steve Ebersole <steve at hibernate.org> wrote:

> 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
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat