This seems odd, de.seimet.photo.entity.Location_$$_javassist_2 should write itself out as a SerializableProxy as well AFAIK. Stuart Scott Marlow wrote: > I was able to reproduce the CNFE issue reported in AS7-5496 (using MySQL > + the test case attached to the jira). > > The jira reports that the CNFE problem only occurs with Hibernate (using > EclipseLink is a workaround). I suspect that EclipseLink might not be > using a proxy for the lazy association but not really sure. According > to the jira, this also used to work with AS5 (older Hibernate). > > During the first EJB client invocation, an entity is returned that > contains a (lazy assocation) proxy that seems to be handled by a call to > readResolve(). During the readResolve(), the original > org.hibernate.proxy.pojo.javassist.SerializableProxy instance is > replaced with a newly generated class > de.seimet.photo.entity.Location_$$_javassist_2 instance. > > However, when the returned entity is passed to the other EJB client > invocation (as a parameter), the generated class > de.seimet.photo.entity.Location_$$_javassist_2, will not be known on the > server side (causing the cnfe.) > > More details are in the jira. > > I'll try using the older version of Hibernate and see if that helps. > > Any other suggestions? > > Scott > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

This seems odd, de.seimet.photo.entity.Location_$$_javassist_2 should write itself out as a SerializableProxy as well AFAIK.

Stuart Scott Marlow wrote: > I was able to reproduce the CNFE issue reported in AS7-5496 (using MySQL > + the test case attached to the jira). > > The jira reports that the CNFE problem only occurs with Hibernate (using > EclipseLink is a workaround). I suspect that EclipseLink might not be > using a proxy for the lazy association but not really sure. According > to the jira, this also used to work with AS5 (older Hibernate). > > During the first EJB client invocation, an entity is returned that > contains a (lazy assocation) proxy that seems to be handled by a call to > readResolve(). During the readResolve(), the original > org.hibernate.proxy.pojo.javassist.SerializableProxy instance is > replaced with a newly generated class > de.seimet.photo.entity.Location_$$_javassist_2 instance. > > However, when the returned entity is passed to the other EJB client > invocation (as a parameter), the generated class > de.seimet.photo.entity.Location_$$_javassist_2, will not be known on the > server side (causing the cnfe.) > > More details are in the jira. > > I'll try using the older version of Hibernate and see if that helps. > > Any other suggestions? > > Scott > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 09/26/2012 08:11 PM, Scott Marlow wrote: > On 09/26/2012 07:07 PM, Stuart Douglas wrote: >> This seems odd, de.seimet.photo.entity.Location_$$_javassist_2 should >> write itself out as a SerializableProxy as well AFAIK. Thinking more about what you said, I need to debug some more...

> > We get the CNFE on the generated > de.seimet.photo.entity.Location_$$_javassist_2 class not being found on > the server side (of the ejb invocation). This happens before we reach > the code that would of invoked the readResolve method. > >> >> Stuart >> >> Scott Marlow wrote: >>> I was able to reproduce the CNFE issue reported in AS7-5496 (using MySQL >>> + the test case attached to the jira). >>> >>> The jira reports that the CNFE problem only occurs with Hibernate (using >>> EclipseLink is a workaround). I suspect that EclipseLink might not be >>> using a proxy for the lazy association but not really sure. According >>> to the jira, this also used to work with AS5 (older Hibernate). >>> >>> During the first EJB client invocation, an entity is returned that >>> contains a (lazy assocation) proxy that seems to be handled by a call to >>> readResolve(). During the readResolve(), the original >>> org.hibernate.proxy.pojo.javassist.SerializableProxy instance is >>> replaced with a newly generated class >>> de.seimet.photo.entity.Location_$$_javassist_2 instance. >>> >>> However, when the returned entity is passed to the other EJB client >>> invocation (as a parameter), the generated class >>> de.seimet.photo.entity.Location_$$_javassist_2, will not be known on the >>> server side (causing the cnfe.) >>> >>> More details are in the jira. >>> >>> I'll try using the older version of Hibernate and see if that helps. >>> >>> Any other suggestions? >>> >>> Scott >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

You're right, Scott; we are indeed cloning the class before performing substitution. I'll have to examine this for a bit to find a good solution... good catch. On 09/27/2012 01:33 PM, Scott Marlow wrote: > On 09/26/2012 08:31 PM, Scott Marlow wrote: >> On 09/26/2012 08:11 PM, Scott Marlow wrote: >>> On 09/26/2012 07:07 PM, Stuart Douglas wrote: >>>> This seems odd, de.seimet.photo.entity.Location_$$_javassist_2 should >>>> write itself out as a SerializableProxy as well AFAIK. >> >> Thinking more about what you said, I need to debug some more... > > Looks like org.jboss.marshalling.cloner.SerializingCloner needs to do > the writeReplace earlier before we start trying to look for the class in > the target deployment classloader. > > After catching the CNFE in the debugger, I looked at > objClass.getDeclaredMethod("writeReplace",null) and that does return: > > public final java.lang.Object > de.seimet.photo.entity.Location_$$_javassist_2.writeReplace() > > CNFE callstack is http://pastie.org/4831038 > > It looks like we are cloning the > de.seimet.photo.entity.Location_$$_javassist_2 class (line 186) but I > wonder if we should wait until after writeReplace() is done to clone the > parameter class. > > What do you think? > >> >>> >>> We get the CNFE on the generated >>> de.seimet.photo.entity.Location_$$_javassist_2 class not being found on >>> the server side (of the ejb invocation). This happens before we reach >>> the code that would of invoked the readResolve method. >>> >>>> >>>> Stuart >>>> >>>> Scott Marlow wrote: >>>>> I was able to reproduce the CNFE issue reported in AS7-5496 (using >>>>> MySQL >>>>> + the test case attached to the jira). >>>>> >>>>> The jira reports that the CNFE problem only occurs with Hibernate >>>>> (using >>>>> EclipseLink is a workaround). I suspect that EclipseLink might >>>>> not be >>>>> using a proxy for the lazy association but not really sure. >>>>> According >>>>> to the jira, this also used to work with AS5 (older Hibernate). >>>>> >>>>> During the first EJB client invocation, an entity is returned that >>>>> contains a (lazy assocation) proxy that seems to be handled by a >>>>> call to >>>>> readResolve(). During the readResolve(), the original >>>>> org.hibernate.proxy.pojo.javassist.SerializableProxy instance is >>>>> replaced with a newly generated class >>>>> de.seimet.photo.entity.Location_$$_javassist_2 instance. >>>>> >>>>> However, when the returned entity is passed to the other EJB client >>>>> invocation (as a parameter), the generated class >>>>> de.seimet.photo.entity.Location_$$_javassist_2, will not be known >>>>> on the >>>>> server side (causing the cnfe.) >>>>> >>>>> More details are in the jira. >>>>> >>>>> I'll try using the older version of Hibernate and see if that helps. >>>>> >>>>> Any other suggestions? >>>>> >>>>> Scott >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >