tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chris derham <>
Subject Re: Session time out never takes place with ajax
Date Thu, 10 Nov 2011 08:24:10 GMT
> So to recap, and verify my understanding...
> Perhaps I am missing some valve overview.
> I understand it is invoked before the filters, but after completion it
> would arrive to the filter/servlet container anyway.
> So what your saying is that if I build a valve and read information from
> IO file or/db or any other cached data which doesn’t trigger a
> request.getSession
> That will work?
> And if so, I will still need to "break" the chain and prevent it from
> continuing deeper into tomcat or else it will update the session access time
> Instead of mapping all requests e.g. /* through security*, you could split
you app. So say /public folder contains static resources and requires not
security*. You could put dynamic resources under /dynamic and map to
security*. That way anybody requesting a dynamic resource would need a
session, and this would be touched on every request to /dynamic/*. If you
had this kind of setup, then you could create another top level folder
called say /ajaxPing and not map that to security*. Then as long as the
filter/servlet/jsp page that fulfills that request does not call
request.getSession, you will fulfill your aim to respond without affecting
session expiration

Alternatively you could put a valve in the front of the whole web app, and
have that respond to a given url, and then stop the request, e.g. not pass
the request to tomcat. I beleive that is what Mr Schultz was suggesting

* when I keep saying security, I'm not sure the correct collective term. I
don't just mean container security, but also any filter/servlet/jsp that
calls request.getSession



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message