[weld-issues] [JBoss JIRA] Commented: (WELD-804) On de-serialization, SerializationProxy should use the same classloader as the one used for creating the proxy

[Marius Bogoevici (JIRA)]

    [ https://issues.jboss.org/browse/WELD-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571643#comment-12571643 ] 

Marius Bogoevici commented on WELD-804:
---------------------------------------

One reason for doing this is to address various deserialization errors that happen in EAR/WAR deployments in JBoss AS, as determining the correct classloader may lead to incorrect results in a hierarchical scenario.

> On de-serialization, SerializationProxy should use the same classloader as the one used for creating the proxy
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WELD-804
>                 URL: https://issues.jboss.org/browse/WELD-804
>             Project: Weld
>          Issue Type: Feature Request
>          Components: Proxies
>    Affects Versions: 1.1.0.CR2
>            Reporter: Marius Bogoevici
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 1.1.0.CR3
>
>
> In 1.1.0.CR2, ProxyFactory may use the classloader of the proxied bean type on proxy class creation, although the recorded proxy supertype is java.lang.Object. On de-serialization, SerializableProxy will try to retrieve the classloader using only the supertype information (which in this case is java.lang.Object). 
> A better solution, proposed by Stuart and implemented here https://github.com/stuartwdouglas/core/tree/proxySerialization is to record the Bean id in the SerializableProxy and use that information for retrieving the classloader deterministically upon deserialization

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira