Just in case someone else is having the same problem, I solved it for
the time being overriding
@Override
protected ISessionStore newSessionStore() {
return new HttpSessionStore(this);
}
in my app. The default configuration of my jetty embedded launcher
seems to keep the session in memory, so it works out of the box. But
other servers could offer other default session store strategies.
Regards
-Carlos
On Feb 19, 2008 6:02 PM, Carlos Pita <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've finally taken the time to trace some insidious reloading filter
> bugs that tend to show up as:
>
> org.apache.wicket.WicketRuntimeException: Parameter clazz must be an
> instance of com.livra.cereza.web.user.login.LoginPage, but is a
> com.livra.cereza.web.layout.CerezaPage
> at org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:269)
>
> The frequency of these bugs have lately reached a level that rendered
> the reloading filter almost useless.
>
> The problem is simple: pages are loaded by the reloading classloader,
> then serialized into diskpagestore, then deserialized
> (diskpagestore.sessionentry.loadpage) in the context of a page loaded
> by another classloader. So they change their classloaders from one
> request to the next.
>
> markupcache tries to compare page classes from different classloaders,
> one coming directly or indirectly from the store, the other not, and
> the history ends in an exception trace that starts like the one above.
>
> Workarounds that come into my mind: *) deserialize pages in the
> context of the wicketfilter classloader, *) use in-memory store for
> working with the reloading classloader.
>
> What do you think? Jean Baptiste?
>
> Thank you in advance
> Regards
> -Carlos
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
