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

[Scott Marlow]

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 <smarlow at redhat.com 
> <mailto:smarlow at 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 <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>
>      > <mailto:smarlow at redhat.com <mailto:smarlow at 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
>      >
>