4:47 p.m.
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 <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> 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/jbo...
Scott
>
> On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>
> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> 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&...
>
> >>>
> >>>
> >>> [2] java.lang.IllegalStateException: Cannot resolve type
> description
> >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation
> >>>
> >>> [3] https://issues.jboss.org/browse/WFLY-11891
>