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

["James Carman" <james@xxxxxxxxxxxxxxxxxxxx>]

Yes, I would map the filter to the same url-pattern that you have for your struts action servlet.  I don’t believe Tomcat HAS that bug he was talking about.  Try deploying the attached WAR file in your Tomcat instance (just drop it in the webapps directory).  I set my session timeout to 1 minute and I log session destruction via a listener.  I’m running 4.1.30 and it works just fine.  All the source code is in the WEB-INF/src directory.  Enjoy!

 

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

 

James;

 

Would it then be reasonable to map the request filter class to the struts action servlet itself?  This way any request through struts would have session checking and validating logic invoked in a centralized fassion.

 

By the way, I set my max inactive interval to 1 minute in my web.xml and there is no sign of the session being expired by the container.  Would the filtering class be a good place to invoke the workaroung logic to check for expired sessions that Joe suggested?

 

Thanks;

 

John Olmstead

James Carman <james@xxxxxxxxxxxxxxxxxxxx> wrote:

-->

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

John Olmstead
jolmstead2k@xxxxxxxxx

---

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

test-webapp.war
Description: Binary data