[
https://issues.apache.org/jira/browse/WICKET-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15960406#comment-15960406
]
Emond Papegaaij commented on WICKET-6353:
-----------------------------------------
This latest commit should restrict the number of reflective calls to
latestUserDefinedLoader() to at most 1 per proxy class. Calling
super.resolveProxyClass first may result in different classes. Note that there
is no right way of doing this. Resolving the class from the Wicket's
classloader may or may not be right, you cannot know. This setup is not very
likely to fail, but when using complex classloader setups, such as osgi or
jboss modules, it might.
If we want to do this entirely right, we should instrument the serialization as
well to add classloader information. However, this would probably require
explicit dependencies on classloader implementations, such as jboss modules.
> Proxy deserialization fails due to classloading issues
> ------------------------------------------------------
>
> Key: WICKET-6353
> URL: https://issues.apache.org/jira/browse/WICKET-6353
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 7.6.0
> Reporter: Emond Papegaaij
>
> JavaSerializer.ClassResolverObjectInputStream overrides resolveClass to
> resolve classes via the Wicket ClassResolvers. This does however not happen
> for resolveProxyClass.
> An example of how this can go wrong:
> * A page with a large component tree is deserialized (war).
> * LinkedMap (used in MarkupContainer) is loaded in a parent ClassLoader (ear).
> * Via this stack, a proxy is hit implementing Spring classes (from the war)
> * Due to LinkedMap determining the latestUserDefinedLoader, the ear-loader is
> used for the lookup of this interface, which fails
> Unfortunately, writing a testcase for this is not easy, so I only have a
> proposed fix: see the classloadingfix branch
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
