I've found the root cause. When checking the timestamps of JSPs, the JSP engine (because it has to access all resources via the Servlet API) requests a URL for the JSP, opens a connection to the URL and then checks the last modified time. This goes directly to the on-disk file.
When reading the content, the request goes via the static resource cache because we can intercept the call to ServletContext.getResourceAsStream() The problem is the following sequence: - request for JSP - no change in JSP timestamp found - cache re-validated (for 5s by default) - JSP is modified (within 5s) - request for JSP (within 5s) - change in JSP timestamp found - JSP content read (sees cached version rather than new version) So we end up with the old version of the JSP content with the updated last modification time. I'm currently looking at options to return a URL for the resource where we can intercept the call to URLConnection.getLastModified(). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
