Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1], which are failing. Here is Scott's PR with the updated tests: [2] When I stepped into org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, I can see that they are failing in ByteBuddy code. I see that: - enhancement of org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets skipped several times in a row; - enhancement of some other classes get skipped; - before trying to enhance org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an exception is thrown. Unfortunately, I'm having trouble getting a good stacktrace to show what happens in ByteBuddy code. Here is what I'm seeing: net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") /* class name differs from run to run */ calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( classLoader, "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" ) calls classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), which returns null; (I don't actually see a class file with this name) returns new TypePool.Resolution.Illegal( "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" ) returns TypePool.Resolution.Illegal Ultimately, TypePool.Resolution.Illegal#resolve( ) throws IllegalStateException, because the type description cannot be resolved. I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy. To build WildFly: ./build.sh clean install -DskipTests=true To run the test: cd testsuite/integration/basic mvn install -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase Help would be very much appreciated. Thanks, Gail [1] https://issues.jboss.org/browse/WFLY-11891 [2] https://github.com/wildfly/wildfly/pull/12180 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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'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

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&... >> >> >> [2] java.lang.IllegalStateException: Cannot resolve type description >> for org.jboss.as.ejb3.SerializationProxyHackImplementation >> >> [3] https://issues.jboss.org/browse/WFLY-11891

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

Should dynamically generated classes be possible to load from a ClassLoader by a name like org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class ?

On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: 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> > <mailto:smarlow@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 >

Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1], which are failing. Here is Scott's PR with the updated tests: [2] When I stepped into org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase, I can see that they are failing in ByteBuddy code. I see that: - enhancement of org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets skipped several times in a row; - enhancement of some other classes get skipped; - before trying to enhance org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an exception is thrown. Unfortunately, I'm having trouble getting a good stacktrace to show what happens in ByteBuddy code. Here is what I'm seeing: net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") /* class name differs from run to run */ calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( " org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5") calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate( classLoader, "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5" ) calls classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"), which returns null; (I don't actually see a class file with this name) returns new TypePool.Resolution.Illegal( "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class" ) returns TypePool.Resolution.Illegal Ultimately, TypePool.Resolution.Illegal#resolve( ) throws IllegalStateException, because the type description cannot be resolved. I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy. To build WildFly: ./build.sh clean install -DskipTests=true To run the test: cd testsuite/integration/basic mvn install -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase Help would be very much appreciated. Thanks, Gail [1] https://issues.jboss.org/browse/WFLY-11891 [2] https://github.com/wildfly/wildfly/pull/12180 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev