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

[Steve Ebersole]

Thats not such a big concern since build-time enhancement is an option...


On Mon 10 Jun 2013 10:34:34 AM CDT, Emmanuel Bernard wrote:
>
> 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
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev