In org.apache.catalina.core.ApplicationDispatcher.doInclude(ServletRequest request, ServletResponse response), after invoke() is called to perform the include, the request and response objects are normally unwrapped. However, if a ServletException or IOException is thrown, the unwrapping does not take place. This leads to problems in environments in which cross context includes are being performed. For example, 1. Web App A performs an include to a Servlet in Web App B 2. The Servlet in Web App B throws a ServletException 3. Web App A catches the ServletException and attempts to forward to an error jsp. Step 3 above will fail due to the fact that the request has not been unwrapped. The active request will contain the ServletContext of web app B and the jsp file will not be found.
Ok. Since I don't want to use a finally for that (as the exception is rethrown in invoke), I think moving the unwrapping in the invoke method (before the code which rethrows the exception) would be appropriate.
That seems like a reasonable solution.
OK, I've moved the ApplicationDispatcher unwrap requests to the invoke method as Remy suggested. Done on both the Tomcat 5.0 and 5.5 CVS branches.
I detect a similar problem with wrapped request at ApplicationDispatcher.forward und include. The wrapped request are not recylced after an exceptions. Arrg! - With STRICT_SERVLET_COMPLAINS this means we have still a HTTPSession memory leak - and at cluster crossContext session replication are not triggered. Currently the only chance I see, is a double try/catch implementation. Look at my checkin at tomcat 5.5.24 revision 545127. But I don't really like the double try/catch for wrapped request! Peter
I'm running into an issue that I think is a side effect of this patch. When forward() calls invoke() the request object now gets unwrapped. Then the forward method again tries to unwrap the already unwrapped request. As a result I am getting a ClassCastException in unwrapRequest (ApplicationDispatcher.java:814). It seems like unwrapRequest should be setting wrappedRequest to null before exiting so subsequent calls to the method don't do anything. Does this seem reasonable?
Mike - having stepped through the code, I don't see the problem you are describing. If you still see the issue, please open a new Bugzilla item and provide the steps to reproduce and/or a simple test war.
I have committed a fix for this that doesn't require additional try/catch/finally blocks. See r572854 (TC5.5.x) and r572856 (TC6.0.x)