This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Comment

It's in at least J2EE 1.3, maybe earlier. The container will notify you when the session expires. (Or well, at least when it unbinds the values) This can be significantly longer than your defined session timeout. Depends on how your container handles it. There might be better ways, but that's how we're currently handling it.

Patrick

Comment

Maybe you could use a Filter that stores a value in the Session object upon first request and then systematically verifies with each subsequent request if the value still exists within the user's session object. If the session timed out, the Filter will not find the value in the user's session object, and can then decide to redirect the user to a page with "a session timed out" message.

Comment

That would not work since users are allowed to use the site without authenticating. Acegi already stores an object in the session, but if the user is authenticated and then the session timesout, I need to detect this, therefore I just can't check for a session object since they would get this message when using the site un-authenticated.

BTW - Since HTTP is stateless, how do you know which is the first request?

Comment

But isn't the issue with Spring is that it always creates a session, therefore a session always exists? I think you point about the cookie makes sense, but since I am now depending on the user's browser settings, I must handle if they will accept this cookie also.[/quote]

Comment

hmm.... interesting point, how does Spring handle if the user will now accept the session cookie? does the framework switch to URL re-writing with the JSESSIONID as a request parameter? hence my earlier question about the useage of the WebContentInterceptor.

Comment

does the framework switch to URL re-writing with the JSESSIONID as a request parameter? hence my earlier question about the useage of the WebContentInterceptor.

It should make no difference to Spring whether sessions are cookie or URL based and there is no standard way to enable or disable URL re-writing.

If you want to use URL re-writing then it is your responsibility to make sure that *every* link in you site is passed through a processor that will re-write it. Have a look at this link for a short description of what you need to do http://www-306.ibm.com/software/webs...401010102.html