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