RE: [cinjug-users] HttpSessionListener Interface and Struts///Session Management

["James Carman" <james@xxxxxxxxxxxxxxxxxxxx>]

You cannot throw the exception in your listener, as the HttpSessionListener interface does not allow you to throw exceptions (other than those extending from RuntimeException).  What I would do (and have done) is place a filter on your webapp which checks the session for some sort of token (or user object) which is placed there upon successful login.  If your filter sees that the token is not there, it redirects to the login page.  This would mean that you have to take care of your own logins, which, in my experience, usually turns out to work out better anyway.

 

 

-----Original Message-----
From: John Olmstead [mailto:jolmstead2k@xxxxxxxxx]
Sent: Thursday, June 03, 2004 9:07 AM
To: Cinjug
Subject: [cinjug-users] HttpSessionListener Interface and Struts///Session Management

 

Ladies and Gentlemen;

 

I have a struts 1.1 application running on Tomcat 4.1.24 and am seeing some strange behaviour when sessions timeout.  I have a session listener class that implements the HttpSessionListener interface and is registered in the web.xml configuration.

 

My expectation and understanding is that when the container invalidates a session due to inactivity, the sessionDestroyed() method of listener interface will be executed. Is this correct???  I would expect that the session would already be invalid by the time this method is executed, but in example implementations of this interface, I see methods being called on session objects that I would expect to be null references based upon the containers action upon the object.

 

I would like to define a ExpiredSessionException, derived from org.apache.struts.util.ModuleException which I would like to throw from the sessionDestroyed() method of the listener when the session is destroyed because of inactivity.  This exception would be defined as a global exception in the struts configuration xml and would map back to the login page of the application.  Since there is nor request object associated with this action, a simple redirect is not available.

 

The desired behaviour is for the application to return to the login page upon session timeout, in the absence of an HttpRequest being generated.   Is this approach and expectations reasonable???

 

Thanks;

 

John Olmstead

John Olmstead
jolmstead2k@xxxxxxxxx

---

Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger