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 <smar...@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 <smar...@redhat.com > >> <mailto:smar...@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@lists.jboss.org > >> <mailto:hibernate-dev@lists.jboss.org> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> > >> > >> > >> -- > >> Regards, > >> Tomek > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev