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: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
