Actually, the generated SerializationProxyHackImplementation class looks to be generated with the application classloader. I assume the same is true for the $$$view5.class.
On 3/22/19 4:01 PM, Gail Badner wrote: > 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 > ? Yes, I think they should be possible to "define" them (not really loading them, since I think they are dynamically generated classes), it seems like ByteBuddy just doesn't like these generated classes for some reason (or something like that). > > On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow <smar...@redhat.com > <mailto:smar...@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/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57 > > Scott > > > > > On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow <smar...@redhat.com > <mailto:smar...@redhat.com> > > <mailto:smar...@redhat.com <mailto:smar...@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&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 > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev