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

[Emmanuel Bernard]

Also more problematically, entity enhancement is at the core of the
recent Hibenate ORM performance improvements. They would be disabled
unless @Vetoed is used. 
And that is problematic as typical industry performance benchmarks we
participate to do not allow for code change (only configuration
changes).

Emmanuel

On Mon 2013-06-10  9:49, Emmanuel Bernard wrote:
> We can't do something as non user friendly :(
> 
> On Mon 2013-06-10  9:10, 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