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

[Scott Marlow]

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