Hello, I encountered an odd situation with request dispatching.
Environment: Java platform: Oracle 1.7 (7u9) Tomcat platform: 7.0.32, 7.0.33 Operating systems: Linux, Windows (likely irrelevant) Browser: Firefox 17 In short, if the same request is first redirected using servlet API RequestDispatcher.forward(), and then via JSTL c:redirect using a relative target, the end result seems incorrect. So, consider a web app with /WEB-INF/web.xml as: <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";> <display-name>RedirT</display-name> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app> ... and /sub/index.jsp as: <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE html> <% RequestDispatcher rd = application.getRequestDispatcher("/"); rd.forward(request, response); %> ... and /index.jsp as: <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE html> <c:redirect url="sub/page.jsp"/> (sub/page.jsp contents omitted as irrelevant for now) Then, consider a request to http://server/context/sub/index.jsp . Looking at the above, I would expect: - the request to be first processed by /sub/index.jsp (this happens) - next by /index.jsp (this happens, too) - ending with showing http://server/context/sub/page.jsp (this doesn't happen!) Instead, the error is "The requested resource (/RedirT/sub/sub/page.jsp) is not available.". Note the "sub" path component being listed twice. So, it is as if the first redirect (using the RequestDispatcher manually, in /sub/index.jsp) fails to reset the "current" location for the requested component from /sub to /, and then subsequently, the c:redirect in /index.jsp adds another "sub" to the request path. If, on the other hand, the latter redirect is done with an address bound to context root (i.e. /sub/page.jsp, instead of sub/page.jsp), the request ends up in the expected place. Also, if the first redirect is done with <c:redirect> rather than the RequestDispatcher, the request ends up in the expected place. This structure looks admittedly odd, but part of that came from producing this SSCCE; the original context was that the initial RequestDispatcher.forward() was located inside a filter class (but similarly, forwarded a request targeted to a resource in a subdirectory to /index.jsp, which in turn contains the c:redirect to another resource within the same subdirectory. I encountered this when moving an application from a WebLogic 9.2 server (where this structure had worked without issues) to a Tomcat server (where this "not found" error appeared. Any comments? Did I come across a but in Tomcat, or a "lucky bug" in the application (i.e. something that worked by luck in the previous container)? While I can (and did) change the application so that the c:redirect in /index.jsp now uses a context-absolute addressing, I'd be interested in hearing the actual verdict. I tried to read the servlet specification, but could not find an exact description covering this case. Thanks, -- ..Juha --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
