Re: Page serialization and reloading don't get on
Carlos Pita schrieb: I would like to see an error page instead, errors of this kind end up showing themselves as obscure page expiration issues that are hard to trace if you don't know where to look. +1 on this one! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page serialization and reloading don't get on
You could throw an Error. Not very nice, but at least you'll notice. Erik. Carlos Pita wrote: ... That said, this will only show error log entries, because of the catch in RequestCycle: I would like to see an error page instead, errors of this kind end up showing themselves as obscure page expiration issues that are hard to trace if you don't know where to look. Regards -Carlos -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page serialization and reloading don't get on
Something like this will do the trick:
class PickyHttpSessionStore extends HttpSessionStore {
public PickyHttpSessionStore(Application application) {
super(application);
}
@Override
public void setAttribute(Request request, String name, Object value) {
try {
ObjectOutputStream stream = new ObjectOutputStream(new
ByteArrayOutputStream());
stream.writeObject(value);
stream.close();
} catch (IOException exception) {
throw new RuntimeException("Unable to serialize
value", exception);
}
super.setAttribute(request, name, value);
}
}
That said, this will only show error log entries, because of the catch
in RequestCycle:
try
{
getSession().requestDetached();
}
catch (RuntimeException re)
{
log.error("there was an error detaching the
request from the
session " + session +
".", re);
}
I would like to see an error page instead, errors of this kind end up
showing themselves as obscure page expiration issues that are hard to
trace if you don't know where to look.
Regards
-Carlos
On Feb 19, 2008 7:59 PM, Carlos Pita <[EMAIL PROTECTED]> wrote:
> > >
> > > 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.
> >
> > Of course it is only a concern when you will deploy with the disk
> > store, and develop with the memory store. If you deploy using the
> > memory store, there isn't much of a problem I suppose.
>
> Mh, now that I think about it twice, a drawback of this approach is
> that you won't be getting page expiration errors and "unable to
> serialize" logs due to non-serializable components until production
> time. Maybe a better alternative is to code a new dummy session store
> that keeps the session in memory but at the same time being picky
> about serialization issues, in order to detect errors earlier. I'll
> wrote something like this and post it later.
>
> Regards
> -Carlos
>
>
> >
> > Martijn
> >
> > --
> >
> > 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]
Re: Page serialization and reloading don't get on
Perhaps the in-memory store can make serialized copies of the state upon storing it in there? On 2/19/08, Carlos Pita <[EMAIL PROTECTED]> wrote: > > > > > > 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. > > > > Of course it is only a concern when you will deploy with the disk > > store, and develop with the memory store. If you deploy using the > > memory store, there isn't much of a problem I suppose. > > Mh, now that I think about it twice, a drawback of this approach is > that you won't be getting page expiration errors and "unable to > serialize" logs due to non-serializable components until production > time. Maybe a better alternative is to code a new dummy session store > that keeps the session in memory but at the same time being picky > about serialization issues, in order to detect errors earlier. I'll > wrote something like this and post it later. > > Regards > -Carlos > > > > > Martijn > > > > -- > > > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page serialization and reloading don't get on
> > > > 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. > > Of course it is only a concern when you will deploy with the disk > store, and develop with the memory store. If you deploy using the > memory store, there isn't much of a problem I suppose. Mh, now that I think about it twice, a drawback of this approach is that you won't be getting page expiration errors and "unable to serialize" logs due to non-serializable components until production time. Maybe a better alternative is to code a new dummy session store that keeps the session in memory but at the same time being picky about serialization issues, in order to detect errors earlier. I'll wrote something like this and post it later. Regards -Carlos > > Martijn > > -- > > 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]
Re: Page serialization and reloading don't get on
On 2/19/08, Carlos Pita <[EMAIL PROTECTED]> wrote: > > 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. Of course it is only a concern when you will deploy with the disk store, and develop with the memory store. If you deploy using the memory store, there isn't much of a problem I suppose. Martijn -- 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]
Re: Page serialization and reloading don't get on
> 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]
Re: Page serialization and reloading don't get on
You should be aware that you now disabled the serialization, which may
cause problems on your production environment if you don't pay
attention to it.
Not a big problem, but something you should be aware of.
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]
Re: Page serialization and reloading don't get on
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]
Page serialization and reloading don't get on
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]
