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

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/m... >>> [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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev