[jboss-as7-dev] Serialization, proxies issue & AS7-5496

[Scott Marlow]

Steve was also right, he thought that we probably are referencing the 
class too early (before writeReplace has occurred).

On 09/27/2012 02:56 PM, David M. Lloyd wrote:
> 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>
>