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

[Gail Badner]

PR: https://github.com/hibernate/hibernate-orm/pull/2825

On Thu, Mar 28, 2019 at 1:49 PM Gail Badner  wrote:

> Hi Guillaume,
>
> I've confirmed that my fix gets the WildFly tests to pass. I've created
> https://hibernate.atlassian.net/browse/HHH-13343.
>
> I'm not sure I understand what you are suggesting by "default behavior".
>
> My proposed fix implements a ClassFileLocator checks if the bytecode
> Hibernate is attempting to enhance is the provided bytecode (by default).
>
> Are you suggesting that ByteBuddy should provide a ClassFileLocator
> implementation that does this?
>
> I'm getting a master PR set up. The tricky bit is to come up with a
> Hibernate unit test that can reproduce this. Scott suggested trying to
> enhance byte code that has already been enhanced, since the enhanced
> bytecode would not be available from the ClassLoader. I'm giving this a
> try.
>
> I will (hopefully) have a PR for master branch shortly.
>
> Regards,
> Gail
>
> On Thu, Mar 28, 2019 at 10:58 AM Guillaume Smet 
> wrote:
>
>> Hi Gail,
>>
>> Thanks for looking into this.
>>
>> Your commit is interesting as we had people in Quarkus complaining about
>> the fact that it was not possible to chain the ORM enhancer after other
>> enhancers as it didn't consider the provided bytes as the "source" to
>> consider.
>>
>> I wonder if what you did (i.e. considering the provided bytes) should be
>> the default behavior.
>>
>> On Thu, Mar 28, 2019 at 7:13 AM Gail Badner  wrote:
>>
>>> Hi Guillaume,
>>>
>>> Unfortunately, it is not so easy.
>>>
>>> typeDescription is of type
>>> TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get
>>> completely resolved until later.
>>>
>>> I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here
>>> is the commit [2].
>>>
>>> I haven't had a chance to try the other tests in Scott's PR. I'll give
>>> them a try tomorrow.
>>>
>>> I did not create a Hibernate issue for this yet because I'm not sure if
>>> Hibernate should be working around this issue.
>>>
>>> It's getting late for me tonight. I'll continue tomorrow.
>>>
>>> Comments are welcome.
>>>
>>> Regards,
>>> Gail
>>>
>>> [1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3
>>> [2]
>>> https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1
>>>
>>> On Tue, Mar 26, 2019 at 10:11 AM Gail Badner  wrote:
>>>
 Guillaume, thanks for the suggestion. I'll give it a try...

 On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet <
 guillaume.s...@gmail.com> wrote:

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

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

[Gail Badner]

Hi Guillaume,

Unfortunately, it is not so easy.

typeDescription is of type
TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get
completely resolved until later.

I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here is
the commit [2].

I haven't had a chance to try the other tests in Scott's PR. I'll give them
a try tomorrow.

I did not create a Hibernate issue for this yet because I'm not sure if
Hibernate should be working around this issue.

It's getting late for me tonight. I'll continue tomorrow.

Comments are welcome.

Regards,
Gail

[1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3
[2]
https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1

On Tue, Mar 26, 2019 at 10:11 AM Gail Badner  wrote:

> Guillaume, thanks for the suggestion. I'll give it a try...
>
> On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet 
> wrote:
>
>> 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  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 > > >> > 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:
>> > >>  >
>> > >>  

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

[Gail Badner]

Guillaume, thanks for the suggestion. I'll give it a try...

On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet 
wrote:

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

Re: [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  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  >> > 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
> >>  >
> >>
> >>
> 

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

[Scott Marlow]

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

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

[Scott Marlow]

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

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

[Scott Marlow]

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

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

[Scott Marlow]

>
>
> >
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57


We should try to recreate without WildFly, perhaps hacking the
SerializationHackProxy code into a Hibernate unit test or ByteBuddy test,
could be our next step, make sense?

Scott

>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Scott Marlow]

Actually, the generated SerializationProxyHackImplementation class looks 
to be generated with the application classloader.  I assume the same is 
true for the $$$view5.class.

On 3/22/19 4:01 PM, Gail Badner wrote:
> 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 
> ?

Yes, I think they should be possible to "define" them (not really 
loading them, since I think they are dynamically generated classes), it 
seems like ByteBuddy just doesn't like these generated classes for some 
reason (or something like that).

> 
> On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow  > 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  
>  > >> 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 

Re: [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  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  > > 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
> >

Re: [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  > 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
>  >>> 

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

[Gail Badner]

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.

On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow  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=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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Scott Marlow]

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=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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Scott Marlow]

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'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=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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Scott Marlow]

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 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=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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Scott Marlow]

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'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=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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Guillaume Smet]

Hi Gail,

Do we have any idea of what this class is supposed to be:
org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ?
Scott, any idea?

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.

If you can give me the Hibernate call which initiates the error, that would
be nice.

And stupid question: we did not have any enhancement test in WildFly before
that?

-- 
Guillaume

On Fri, Mar 22, 2019 at 7:59 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
> 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