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

On 3/22/19 1:53 PM, Gail Badner wrote: > 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. I'm guessing that the SLSBPersistenceContexts$$$viewX classes are generated by the WildFly EJB container, for the (test) application EJB bean org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts. I'm not sure why the failure is varying between different classes. For the weird org.jboss.as.ejb3.SerializationProxyHackImplementation failure, SerializationProxyHackImplementation is a dynamically generated server class apparently, that comes from https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... Scott > > 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 >