Craig, I thoght the token mechanism could have helped here. Am I wrong?
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 11, 2001 10:30 PM
Subject: Re: Handling session timeouts
> On Wed, 6 Jun 2001, Andreas Prohaska wrote:
>
> >
> > This was originally posted to the struts-user list, but Ted Husted
pointed
> > out that I should better discuss this on the development list.
> >
> > For the guys that are not listening to the user list, the background: We
> > have written a wizard for a larger input process that requires some
steps.
> > We use one ActionForm bean for this wizard that keeps the data in the
> > session context (everything done by struts). When I wanted to go to the
next
> > step I recognized that all my data from the previous steps was lost and
> > instead I had the default values. Obviously a session timeout occured
and
> > the original ActionForm was removed. Then a new session was
automatically
> > created and a new ActionForm bean was automatically added to the session
> > context. Normally this is nice, but there was no way for my Action class
or
> > JSP to see that in fact the session was lost and the data was wrong.
> >
> > Now I would recommend to place a method like processSession() at the
start
> > of the process() method in the ActionServlet. This could be changed by
> > subclasses of the ActionServlet in order to intercept session creation
and
> > deprecation. OR it should call some more specialized class for this (say
> > SessionManager). The advantage of this approach would be that we could
also
> > introduce a new <page:init> tag that calls the same class in order to
> > intercept session creation in JSP pages (that might be called directly).
> >
> > If the list decides that this could be nice, I would make the changes
but
> > then I need to know how I can submit them :-)
> >
> > What do you think?
> >
>
> In servlet 2.2, there is *no* general event handling mechanism that can
> catch a session creation no matter where it happened. In order to make
> something like this work in Struts, we would have to place restrictions
> like this:
>
> * The action cannot call request.getSession() -- it must call some
> Struts-provided method that will detect the creation.
>
> * The user cannot *ever* call a JSP page directly, because the session
> will be created (or recreated) as necessary.
>
> Most people work around this by a strategy like this:
>
> * At logon time, place an attribute into the session under a
> well-known key. The Struts example app uses the User object
> for this purpose.
>
> * At the beginning of each action (or page), check for the
> existence of the well-known attribute. If it is missing,
> this is a new session (possibly a replacement for a timed-out
> one). In the example app, there's an <app:checkLogon> custom
> tag that can do this.
>
> * If a session times out (or is invalidated), all of the attributes
> will be removed. If you want to know when either of these things
> happens, simply make your attribute implement HttpSessionBindingListener
> and it will be notified at timeout or invalidate time.
>
> The servlet 2.3 specification includes new application event listeners for
> session created, session destroyed, and add/change/delete of session
> attributes. Then you'll be able to build apps that react to such events
> without having to involve specific attributes -- but until then we are
> kind of stuck.
>
>
>
> > Andreas
> >
>
> Craig McClanahan
>
