[
https://issues.apache.org/jira/browse/WICKET-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15959073#comment-15959073
]
Sven Meier commented on WICKET-6353:
------------------------------------
So we have the following call hierarchies now:
{code}
resolveClass() {
try {
super.resolveClass()
} catch {
resolveClassInWicket()
}
}
resolveProxyClass() {
resolveClassByName
try {
Class.forName(latestUserDefinedLoader())
} catch {
resolveClassInWicket()
}
}
{code}
Why this discrepancy? And do we really need to fiddle with
latestUserDefinedLoader() now?
Wouldn't it be better to call the super implementation first? Let it handle the
latestUserDefinedLoader (your code is doing reflection twice now for each
proxy).
For most deployments this will work just fine, and users won't have to pay a
penalty (performance and stability) if they don't need to. If it fails, we can
use resolveClassInWicket() as a fallback - but only for those who need it.
> 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)
