Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

I just wanted to clarify that sometimes I was seeing problems with SerializationProxyHackImplementation. When debugging, I usually saw a failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1 and 9.

On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: On 3/22/19 10:08 AM, Scott Marlow wrote: > > > 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 tried changing org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform() to filter out any non-application classes but that didn't help as DelegatingClassFileTransformer.transform() doesn't get called to transform the SerializationProxyHackImplementation [2] class. It might be that the application classes are getting injected with a classloader that references the SerializationProxyHackImplementation [2] class. IMO, this probably should be fixed in Hibernate ORM or ByteBuddy. > >> >>> >>> 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&... >>> >>> >>> [2] java.lang.IllegalStateException: Cannot resolve type description >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation >>> >>> [3] https://issues.jboss.org/browse/WFLY-11891