[hibernate-dev] WildFly tests with ByteBuddy enhancement are failing
Scott Marlow
smarlow at redhat.com
Fri Mar 22 10:08:09 EDT 2019
On 3/22/19 9:24 AM, Scott Marlow wrote:
>
>
> On 3/22/19 9:11 AM, Scott Marlow wrote:
>>
>>
>> On 3/22/19 7:49 AM, Guillaume Smet wrote:
>>> Hi Gail,
>>>
>>> Do we have any idea of what this class is supposed to be:
>>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5
>>> ?
>>
>> This is a unit test class that is not an entity class, but instead it
>> happens to be an EJB stateless session bean. In the exception call
>> stack [1], the class that ByteBuddy complains about is a WildFly class
>> (not even a test class), you can see that in the exception message
>> SerializationProxyHackImplementation [2].
>>
>>> Scott, any idea?
>>
>> I was not really aware that classes like
>> SerializationProxyHackImplementation [2] , would also be handled by
>> org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform()
>> but I guess that makes sense, as application classloaders versus
>> application module classloaders, are not distinguished internally in WF.
>
> I meant that class file transformers will be called for both application
> classes and WF classes as well.
I'm going to see if I can hack around this failure in WF code, so that
WF doesn't call into Hibernate to transform the
org.jboss.as.ejb3.SerializationProxyHackImplementation class.
>
>>
>> I'm also not sure of how Javassist handles ignoring the
>> SerializationProxyHackImplementation [2] class but Javassist does work
>> fine (as long as you work around the other issue, which is that
>> Javassist can only be selected via system property setting but not
>> persistence.xml setting, also mentioned in WFLY-11891 [3]).
>>
>>>
>>> Because it doesn't ring a bell on my side.
>>>
>>> I suspect it's a class we shouldn't access or touch. And we should
>>> probably
>>> add a condition somewhere to avoid doing so.
>>
>> Agreed.
>>
>>>
>>> If you can give me the Hibernate call which initiates the error, that
>>> would
>>> be nice.
>>
>> [1] shows the exception call stack (look for
>> "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)"
>>
>>
>>
>>>
>>> And stupid question: we did not have any enhancement test in WildFly
>>> before
>>> that?
>>>
>>
>> No, sadly, this is the first time we updated the WildFly unit tests to
>> try Javassist + ByteBuddy enhancement. Its a very light test with
>> little verification, basically we just modified some existing tests to
>> include:
>>
>> hibernate.enhancer.enableDirtyTracking=true
>> hibernate.enhancer.enableLazyInitialization=true
>> hibernate.enhancer.enableAssociationManagement=true
>>
>> And one test was also modified to specify
>> hibernate.bytecode.provider=javassist, which is ignored (only the
>> system property works, via standalone.sh
>> -Dhibernate.bytecode.provider=javassist). The problem is also
>> mentioned in WFLY-11891 [3].
>>
>> In WF, we also have a mock persistence provider test that ensures that
>> persistence providers can enhance classes as per the JPA container
>> contract.
>>
>> Scott
>>
>> [1]
>> https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809
>>
>>
>> [2] java.lang.IllegalStateException: Cannot resolve type description
>> for org.jboss.as.ejb3.SerializationProxyHackImplementation
>>
>> [3] https://issues.jboss.org/browse/WFLY-11891
More information about the hibernate-dev
mailing list