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

David M. Lloyd david.lloyd at redhat.com
Thu Sep 27 14:56:09 EDT 2012


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
>>
>


-- 
- DML




More information about the jboss-as7-dev mailing list