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

[hibernate-dev] Hibernate Search 6.0.0.Alpha3 released

[Yoann Rodiere]

Hello,

We just published Hibernate Search 6.0.0.Alpha3, the third release for the
still-in-development 6.0 branch. This release mainly adds support for more
field types and predicates, and brings more consistent and less verbose
APIs.

This version is an early technology preview, so be sure to read about it on
our blog before you try it out:

http://in.relation.to/2019/03/22/hibernate-search-6-0-0-Alpha3/
Cheers,

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
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

[hibernate-dev] Hibernate ORM 5.4.2.Final released

[Guillaume Smet]

Hi,

We just released Hibernate ORM 5.4.2.Final.

More information here:
http://in.relation.to/2019/03/22/hibernate-orm-542-final-out/ .

Have a nice day.

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

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

[Gail Badner]

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