[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