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

[Gail Badner]

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