> > 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 HTH Chris
