struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mitchell" <jmitch...@apache.org>
Subject Re: Best practice for redirecting on session timeout?
Date Thu, 12 May 2005 15:02:08 GMT
----- Original Message ----- 
From: <struts@aladin.ca>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Thursday, May 12, 2005 10:34 AM
Subject: Re: Best practice for redirecting on session timeout?


> Although this approach might work, I don't like it so much.  The reasons:
>
> 1) Maintainability: if you want to change the timeout to 30 minutes (and
> you have 50 jsp pages), then you have to make the change 50 times.


Umm..ya...that's why I explicity said "preferrably via an include or let a 
filter do it for you".


>
> 2) Business Logic: This approach will never prevent you Action from
> executing.  Since you have to go through an action to reach the jsp page,
> when the *page* reloads, you are actually reloading the action first.

Actually, no, that's not at all what I said.

> Having said that, if your action does something that should only be
> executed if your session has not expired, your approach will not work.

You must be confused here.  The refresh happens ON the client after 20 
minutes of inactivity.  "Inactivity" being defined as "the browser has no 
interaction with the server".

The solution I offer is a way to "force" the browser to hit the server 
(after the specified time has passed), which the server can then deal with 
(the expired session).

>
> A combination of using a filter & session-config (in web.xml) solves both
> problems above.  How?
>
> 1) You only have to change the session timeout setting in one place.
>
> 2) Your filter is executed before anything else.  Hence, you never have to
> worry about an action being executed unintentionally.
>
> Aladin
>

That's correct, (sort of) but that's really only 1 of 42 ways to solve this 
problem.  What you presume by your above statements is that someone has 
coded their app with a flat implementation of actions (e.g. no base 
actions).  This is considered to be a bad practice.  You will always want a 
single point of entry into your peice of the controller.  You do this easily 
with BaseActions.  Besides reuse, you can solve the above situation quite 
easily.

After rereading the original post, it seems that I misunderstood the 
original question.  My proposed solution assumes you've already dealt with 
handling the expired session, so for all intents and purposes, we actually 
agree (in a 1/42 kind of way ;)


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
Yahoo: jmitchtx
MSN:   jmitchell@apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message