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]

Reply via email to