> You should be aware that you now disabled the serialization, which may
> cause problems on your production environment if you don't pay
Of course, I'm proposing this just for >development environments that
use the reloading filter<. Thanks for the remark, anyway. Perhaps I
should have been clearer, as I'm throwing this in the open.
Regards
-Carlos
> Martijn
>
>
> On 2/19/08, Carlos Pita <[EMAIL PROTECTED]> wrote:
> > 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]
> >
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
