tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
Date Wed, 05 Jan 2005 17:47:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=25965>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965


galwar@nvisia.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Additional Comments From galwar@nvisia.com  2005-01-05 18:47 -------
You are incorrect when you say that he is not obtaining the RD from context B.
He is. Please check the code carefully. Here is the scenario:

There are two applications deployed to Tomcat: client.war (application A) and
server.war (application B). Application A has a servlet called ClientServlet
that is mapped to "/c". Application B has a servlet called ServerServlet that is
mapped to "/serverservlet"

Here is the sequence of events:
1) Browser sends a request to http://localhost:8080/client/c.
2) Tomcat maps request to A (client.war gets the /client context root) and
invokes ClientServlet:service()
3) In ClientServlet:service(), he is getting the application context for B as
follows:
   ServletContext serverServletContext = 
                         getServletContext().getContext(SERVER_CONTEXT_ROOT);
   where SERVER_CONTEXT_ROOT is "/server" (server.war gets the /server context
root). Please look up the API for the getContext() method call on the
ServletContext object. This is how one can do server-side includes of content
from servlets/resources in another application that is deployed on the same server.
4) He is then obtaining the request dispatcher using B's servlet context not his
own (A's) servlet context:
   RequestDispatcher requestDispatcher =
               serverServletContext.getRequestDispatcher(SERVER_SERVLET_PATH);
   where SERVER_SERVLET_PATH is "/serverservlet", the path mapped to B's
servlet. I think this is the point you are not following. He is not doing
getServletContext().getRequestDispatcher(SERVER_SERVLET_PATH) which would be
using A's servlet context. 
5) He finally does an include of B's servlet by calling:
   requestDispatcher.include(httpServletRequest, httpServletResponse);
   
   Now although the request first arrived in A, it is not A's request
exclusively. A request represents a user request to the server and can be
forwarded to another application or you can include servlets/resources from
another application. The server of course can prohibit this due to security
constraints. In Tomcat one can override the security restrictions by setting
"crossContext" to "true" in the <Context> element for application A in
server.xml to allow servlets in A to obtain servlet contexts to other
applications (such as B). 

   With "crossContext" set to "true" for the client application (A), Tomcat
returns a servlet context to B in Step 3. It also returns a request dispatcher
to B's servlet in Step 4. The include call also works in Step 5 and B's servlet
is called correctly. However, when B's servlet gets a request dispatcher to
"/test.jsp" and does an include of it, Tomcat is looking for "/test.jsp" in
application A! THIS IS A BUG! One can verify this by creating a test.jsp file in
the root of the WAR in application A and see that it is being called instead. 
   
   Please do not rush and close this as "invalid". This is definitely a bug.
Please talk to other Tomcat developers if you must and work towards resolving this. 
   


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message