DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||INVALID
--- Additional Comments From [EMAIL PROTECTED] 2005-01-05 21:56 ---
There are two request dispatchers in this test case. The first is obtained as
you describe (and works correctly) but this is not the dispatcher used to
include test.jsp.
A second request dispatcher is created in the service() method of the
ServerServlet in server.war/context B. The code for this method is:
public void service(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse)
throws ServletException, IOException
{
httpServletResponse.setContentType(text/html);
RequestDispatcher dispatcher =
httpServletRequest.getRequestDispatcher(TEST_JSP);
dispatcher.include(httpServletRequest, httpServletResponse);
}
The request dispatcher is obtained from the request. Because this is an include,
the request is the original request that is associated the client/context A.
Hence this request dispatcher cannot find test.jsp which is in context B.
I would also point out that when originally investigating this bug I downloaded
the test case and stepped through it line by line in a debugger to check exactly
what was going on before closing it as invalid.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 --- Additional Comments From [EMAIL PROTECTED] 2005-01-05 22:14 --- It seems that the relevant part of the spec is: spec-quote version=2.3 section=14.2.16.1 The pathname specified may be relative, although it cannot extend outside the current servlet context. If the path begins with a / it is interpreted as relative to the current context root. This method returns null if the servlet container cannot return a RequestDispatcher. /spec-quote So it seems to hinge on what the current context is in this case. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 00:50 --- Let me approach this from a different angle to impress upon you that this is a bug. What is the point of invoking a servlet in another application if one is expected to provide all the resources (JSPs etc.) that is going to be included by that servlet? Think about this for a second. It is very likely that someone else wrote application B and its purpose is entirely different from application A. The folks that wrote application B packaged their application with JSPs/HTML files etc. that are included/forwarded to by their servlet. If I write application A and want to invoke a servlet in application B, am I expected to know what are all the resources included/forwarded by the servlet in application B and in addition provide them in my application??? That is what you are effectively saying and it makes no sense. This is a bug in Tomcat. Thanks to William for pointing out the spec. If the request is currently being processed by the servlet in application B, then the current servlet context is clearly B and not A. At the risk of repetition, it doesn't matter that the request came to application A first. Application A passed along the request to a servlet in application B after obtaining the servlet context for B and hence we are in B's context now. The resources should then be looked up in application B not application A. Please stop dismissing this as invalid as this is a bug (it is quite irritating to reopen it again and again). I ran this example in another server (Weblogic 8.1) and it worked flawlessly (the resource was looked up in application B and not application A). At the very least, leave it as REOPENED so that other folks can provide their input. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 01:00 --- Please do not bother reopening the report, unless you have more time to waste. If you're only doing includes, the top level path will always be used. With forwards, it's the opposite. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 01:27 --- The following quotes are from section SRV.14.2.5.1 (RequestDispatcher methods) of the spec. spec-quote public void forward(ServletRequest request, ServletResponse response) throws ServletException, IOException Forwards a request from a servlet to another resource (servlet, JSP file, or HTML file) on the server. This method allows one servlet to do preliminary processing of a request and another resource to generate the response. For a RequestDispatcher obtained via getRequestDispatcher(), the ServletRequest object has its path elements and parameters adjusted to match the path of the target resource. ... The request and response parameters must be either the same objects as were passed to the calling servlets service method or be subclasses of the ServletRequestWrapper or ServletResponseWrapper classes that wrap them. /spec-quote spec-quote public void include(ServletRequest request, ServletResponse response) throws ServletException, IOException Includes the content of a resource (servlet, JSP page, HTML file) in the response. In essence, this method enables programmatic server-side includes. The ServletResponse object has its path elements and parameters remain unchanged from the callers. The included servlet cannot change the response status code or set headers; any attempt to make a change is ignored. The request and response parameters must be either the same objects as were passed to the calling servlets service method or be subclasses of the ServletRequestWrapper or ServletResponseWrapper classes that wrap them. /spec-quote To address the question raised by Bill above, ie what is the current servlet context consider the case of a relative path. Relative paths are, by definition, relative to the current request. The current request (since we are doing includes not forwards) is still the original request (to context A). Hence the path is relative to the original request. Since it is relative to the original request the path must be within the original servlet context. Therefore, the current servlet context must be the original context (client or context A in the discussion above). -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-01-06 04:21 --- FYI, I deployed the client.war and server.war (attached to this bug report by Scott) to the Sun One Application Server 8.1 and it worked as I expected (the RD obtained by ServerServlet in application B correctly includes /test.jsp in application B). That's two servers so far that I have tested where it works (Weblogic 8.1 and Sun One Application Server 8.1 2005Q1). I would imagine that Sun got the implementation correct on their own spec? Mark: You stated Relative paths are, by definition, relative to the current request. I believe that they are relative to the root of the current application context. This might be why the the getRequestDispatcher() method exists in the ServletContext (and not in the request). Remy: I do not think it is a waste of time to report bugs or to discuss spec. compliance so that Tomcat conforms to it. My goal is the same as yours - to improve Tomcat. Otherwise, I would not be spending all this time posting. I hope you would welcome folks reporting bugs and encourage discussion going forward instead of dismissing them as a waste of time. I am moving the status to REOPENED. I hope that you will recognize that this is a bug after all and not continue to insist that Tomcat's implementation is correct and others (Sun, BEA etc) are incorrect. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 18:55 --- This appears to be a Tomcat bug. AController (the servlet in application A) obtains a context to application B. If Tomcat does not allow this for security reasons, it should return null here (as per the API). If Tomcat returns a context, then this context should be the application context for application B, the same one that we will deal with if the user directly posted to application B. When a request dispatcher is obtained from this new context, we are dealing entirely with resources in context B (the fact that the request originated from application A is irrelevent at this point since we are dealing with a new context). Hence, if test.jsp exists in application B, Tomcat should find it. If Tomcat instead looks for test.jsp in application A, it is incorrect since Tomcat is crossing boundaries (from B to A) that is shouldn't because as I mentioned before we are working with the application context for application B. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 23:27 --- In the original post, and in the provided test case, the request dispatcher is obtained from the original context A request. It is not obtained from context B. Your analysis is wrong. This bug is invalid. The sequence of events you are describing is fundamentally different because you get the RD from context B, not from the request. If you have a test WAR for your sequence of events that you believe deomnstrates invalid behaviour please open a new bug report and attach you WAR. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
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 RequestDispatcher fails after cross context include [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-24 16:33 --- In your original post and in your provided test cases test.jsp is in application B. In application B you obtain an RequestDispatcher from the request (which originated in application A) and hence can't find test.jsp Your test case is invalid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 01:22 --- Created an attachment (id=9970) This is the client web app of the test case. Browse to index.jsp to invoke the test. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 01:23 --- Created an attachment (id=9971) This is the server web app of the test case. It's invoked through the client web app (also attached) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 01:26 --- I've sent an e-mail regarding this bug to both mailing lists and did not recieve a response. Therefore, I've attached the test case (two war files) and have reopened the issue. Please let me know if you cannot reproduce the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-07 19:09 --- It's too bad you didn't discuss this with anyone on the user or dev lists without posting, or this would have been explained to you. Bugzilla is a resort to be used after pursuing matters on the mailing lists. Make sure you understand the RequestDispatcher functionality, especially notes like The pathname specified may be relative, although it cannot extend outside the current servlet context (from ServletRequest#getRequestDispatcher's javadoc). Without seeing your webapp code, it's impossible to say whether this is an issue or not, so I'm dismissing it as invalid for now. Provide your two web applications as WARs attached to this item, if you choose to reopen it after discussing on the mailing lists. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include --- Additional Comments From [EMAIL PROTECTED] 2004-01-07 19:28 --- I believe that you misunderstood the bug. I'm trying to include a jsp file within the same application. The basic flow is: AController (Web App A) -- BController (Web App B) -- test.jsp (Web App A) The first include is acheived through the following code: ServletContext bServletContext = getServletContext().getContext(B_CONTEXT_ROOT); RequestDispatcher requestDispatcher = bServletContext.getRequestDispatcher (B_CONTROLLER_SERVLET_PATH); requestDispatcher.include(httpServletRequest, httpServletResponse); I'll bring it up on the mailing list, though, as you suggested. I apologize for not doing this first. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
