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

[Guillaume Smet]

I would try changing the start of EnhancerImpl#enhance() to:
=======
    public byte[] enhance(String className, byte[] originalBytes) throws
EnhancementException {
        //Classpool#describe does not accept '/' in the description name as
it expects a class name. See HHH-12545
        final String safeClassName = className.replace( '/', '.' );
        try {
            final Resolution typeResolution = typePool.describe(
safeClassName );
            if ( !typeResolution.isResolved() ) {
                return null;
            }

            final TypeDescription typeDescription =
typeResolution.resolve();
=======

i.e. testing the resolution of the type.

That might fix it.

-- 
Guillaume

On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow <smarlow at redhat.com> wrote:

> Thinking more about this, I don't think that ByteBuddy should be able to
> do a classloader.getResource() on the class that is being defined
> (SLSBPersistenceContexts$$$view5.class).  It might be correct for the
> getResource call to return null, until after the class is completely
> defined.
>
> Would it make sense for the above condition (cl.getResource() returning
> null) be detected differently in the callstack [1] and just fall through
> + return to the caller?
>
> Scott
>
> [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd
>
> On 3/26/19 9:53 AM, Scott Marlow wrote:
> > Hi Tomek,
> >
> > I think the pending question now is why ByteBuddy is getting a null
> > result from the
> >
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>
> > call.
> >
> > We have also seen failures for
> > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is
> > also generated by the EJB container (see exception call stack in
> > https://issues.jboss.org/browse/WFLY-11891).
> >
> > I wonder if this could be an ordering bug where classes generated via
> > JBoss ClassFileWriter are added to the classloader list of classes,
> > before the actual bytecode is added.
> >
> > Scott
> >
> > On 3/26/19 9:17 AM, Tomasz Adamski wrote:
> >> Hi Scott,
> >>
> >> Added to my TODO. WIll try to look at it this week.
> >>
> >> Regards,
> >> Tomek
> >>
> >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow <smarlow at redhat.com
> >> <mailto:smarlow at redhat.com>> wrote:
> >>
> >>     Adding Tomek + Cheng, as they have been working on the WildFly EJB
> >>     layer
> >>     recently, which seems to use
> >>     https://github.com/jbossas/jboss-classfilewriter for generating
> >> the EJB
> >>     stub classes like
> >>
> >>
> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
>
> >>
> >>
> >>     Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
> >>     ByteBuddy should change to handle dynamically generated classes
> >>     differently.
> >>
> >>     In other words, should ByteBuddy respond differently to
> >>
> >>
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>
> >>
> >>
> >>     returning null or should the jboss-classfilewriter project somehow
> >>     avoid
> >>     this bug.
> >>
> >>     Scott
> >>
> >>     On 3/22/19 2:54 AM, Gail Badner wrote:
> >>      > 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 at lists.jboss.org
> >> <mailto:hibernate-dev at lists.jboss.org>
> >>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>      >
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Tomek
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev