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
).
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(a)redhat.com
<mailto:smarlow@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Regards,
Tomek