RE: RequestDispatcher.forward() to doc located on HTTP Server
Forward only works within a context -Original Message- From: Ron Crayton [mailto:[EMAIL PROTECTED] Sent: 11 April 2005 19:36 To: tomcat-user@jakarta.apache.org Subject: RequestDispatcher.forward() to doc located on HTTP Server Is it possible to use Request.forward() to forward a request to an html document located on an HTTP Server? I'm using Tomcat 5.5.7 and Apache 2.0. I have a document setting in the htdocs folder of Apache 2.0 that I'm trying to forward to from an application deployed in Tomcat 5.5.7. I have this context in my server.xml file: Context path=/LoginApp docBase=LoginApp debug=0 reloadable=true crossContext=true Logger className=org.apache.catalina.logger.FileLogger prefix=LoginApp. suffix=.log timestamp=true/ /Context I have this code in my app: ServletContext context = getServletConfig().getServletContext(); String uri = request.getQueryString(); ServletContext foreignContext = context.getContext(/); RequestDispatcher requestDispatcher = foreignContext.getRequestDispatcher(uri); requestDispatcher.forward(request, response); The uri comes from the query string of the original request. When the code runs it says that the requested resource is not available - Error 404. Am I trying to do something that's impossible? Please help. - Do you Yahoo!? Yahoo! Small Business - Try our new resources site! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward() to doc located on HTTP Server
You might have better luck using a redirect. This should cause the client to request the alternate resource which Apache would then serve. Mark Ron Crayton wrote: Is it possible to use Request.forward() to forward a request to an html document located on an HTTP Server? I'm using Tomcat 5.5.7 and Apache 2.0. I have a document setting in the htdocs folder of Apache 2.0 that I'm trying to forward to from an application deployed in Tomcat 5.5.7. I have this context in my server.xml file: Context path=/LoginApp docBase=LoginApp debug=0 reloadable=true crossContext=true Logger className=org.apache.catalina.logger.FileLogger prefix=LoginApp. suffix=.log timestamp=true/ /Context I have this code in my app: ServletContext context = getServletConfig().getServletContext(); String uri = request.getQueryString(); ServletContext foreignContext = context.getContext(/); RequestDispatcher requestDispatcher = foreignContext.getRequestDispatcher(uri); requestDispatcher.forward(request, response); The uri comes from the query string of the original request. When the code runs it says that the requested resource is not available - Error 404. Am I trying to do something that's impossible? Please help. - Do you Yahoo!? Yahoo! Small Business - Try our new resources site! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward: SOLVED
Thanks to Tim and Remy for the answers;
For more explanations for those who have the same problem like me :
- see bugs 23211 and 33831 on http://issues.apache.org/bugzilla/
- In my example,
after ctx = ctx.getContext(/myNewContext);
but before dispatcher = ctx.getRequestDispatcher(/myNewServlet);
I can verify if my context (ctx) is the good one (or the context root) thanks
to :
ctx.getServletContextName() //if servlet API is 2.4
or ctx.getInitParameterNames() return a initParameter present in my
desired Context
or ctx.getAttributeNames() return an attribute present in my desired
Context
or ctx.getRealPath(/myNewServlet) is a Path valid for my desired Context
On Wed, 2 Mar 2005 16:34:42 +0100
Lionel Farbos [EMAIL PROTECTED] wrote:
Yes : it's my problem.
ctx.getContext(/myNewContext) always return a Context (even if myNewContext
is not deployed :-(
and
ctx.getRequestDispatcher(/myNewServlet) always return a dispatcher (even if
myNewServlet is not here :-(
So How can I avoid a 404 ?
On Wed, 02 Mar 2005 10:24:37 -0500
Tim Funk [EMAIL PROTECTED] wrote:
getRequestDispatcher() will always return a servlet. (The default servlet)
-Tim
Lionel Farbos wrote:
Hi,
(I work on Tomcat 5.0.30).
When my servlet (http://myVhost/proxy/testProxy) forward to another
servlet :
try {
ServletContext ctx = getServletContext();
ctx = ctx.getContext(/myNewContext);
RequestDispatcher dispatcher =
ctx.getRequestDispatcher(/myNewServlet);
dispatcher.forward(request, response);
} catch (Exception e) {e.printStackTrace();}
(in server.xml, in the Context /proxy of myVhost, I put
crossContext=true)
If the Context /myNewContext is deployed in myVhost, the HTTPresponse is :
HTTP/1.1 200 OK
...
response of myNewServlet
If the Context /myNewContext is not deployed, the HTTPresponse is :
HTTP/1.1 404 /myNewServlet
:-(
1) In other servlets containers, I read that
ctx.getRequestDispatcher(...) returns null if the resource is absent.
So, Why Tomcat reacts differently ? Is it a bug ?
2) In my case, I'd want to forward to myNewServlet if it is present, BUT,
if it is absent, I'd want to call another url distant (with httpclient)...
How can I do this with Tomcat ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward: a bug?
getRequestDispatcher() will always return a servlet. (The default servlet)
-Tim
Lionel Farbos wrote:
Hi,
(I work on Tomcat 5.0.30).
When my servlet (http://myVhost/proxy/testProxy) forward to another servlet :
try {
ServletContext ctx = getServletContext();
ctx = ctx.getContext(/myNewContext);
RequestDispatcher dispatcher = ctx.getRequestDispatcher(/myNewServlet);
dispatcher.forward(request, response);
} catch (Exception e) {e.printStackTrace();}
(in server.xml, in the Context /proxy of myVhost, I put crossContext=true)
If the Context /myNewContext is deployed in myVhost, the HTTPresponse is :
HTTP/1.1 200 OK
...
response of myNewServlet
If the Context /myNewContext is not deployed, the HTTPresponse is :
HTTP/1.1 404 /myNewServlet
:-(
1) In other servlets containers, I read that ctx.getRequestDispatcher(...)
returns null if the resource is absent.
So, Why Tomcat reacts differently ? Is it a bug ?
2) In my case, I'd want to forward to myNewServlet if it is present, BUT, if it is absent, I'd want to call another url distant (with httpclient)...
How can I do this with Tomcat ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward: a bug?
Yes : it's my problem.
ctx.getContext(/myNewContext) always return a Context (even if myNewContext
is not deployed :-(
and
ctx.getRequestDispatcher(/myNewServlet) always return a dispatcher (even if
myNewServlet is not here :-(
So How can I avoid a 404 ?
On Wed, 02 Mar 2005 10:24:37 -0500
Tim Funk [EMAIL PROTECTED] wrote:
getRequestDispatcher() will always return a servlet. (The default servlet)
-Tim
Lionel Farbos wrote:
Hi,
(I work on Tomcat 5.0.30).
When my servlet (http://myVhost/proxy/testProxy) forward to another servlet
:
try {
ServletContext ctx = getServletContext();
ctx = ctx.getContext(/myNewContext);
RequestDispatcher dispatcher = ctx.getRequestDispatcher(/myNewServlet);
dispatcher.forward(request, response);
} catch (Exception e) {e.printStackTrace();}
(in server.xml, in the Context /proxy of myVhost, I put crossContext=true)
If the Context /myNewContext is deployed in myVhost, the HTTPresponse is :
HTTP/1.1 200 OK
...
response of myNewServlet
If the Context /myNewContext is not deployed, the HTTPresponse is :
HTTP/1.1 404 /myNewServlet
:-(
1) In other servlets containers, I read that ctx.getRequestDispatcher(...)
returns null if the resource is absent.
So, Why Tomcat reacts differently ? Is it a bug ?
2) In my case, I'd want to forward to myNewServlet if it is present, BUT,
if it is absent, I'd want to call another url distant (with httpclient)...
How can I do this with Tomcat ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() forgets requestUri
Hi, I strongly suggest (to anyone on the list not having done so) reading the Servlet Specification: SRV.8.3.1 Included Request Parameters Except for servlets obtained by using the getNamedDispatcher method, a servlet that has been invoked by another servlet using the include method of RequestDispatcher has access to the path by which it was invoked. The following request attributes must be set: javax.servlet.include.request_uri javax.servlet.include.context_path javax.servlet.include.servlet_path javax.servlet.include.path_info javax.servlet.include.query_string These attributes are accessible from the included servlet via the getAttribute method on the request object and their values must be equal to the request URI, context path, servlet path, path info, and query string of the included servlet, respectively. If the request is subsequently included, these attributes are replaced for that include. If the included servlet was obtained by using the getNamedDispatcher method, these attributes must not be set. SRV.8.4 The Forward Method The forward method of the RequestDispatcher interface may be called by the calling servlet only when no output has been committed to the client. If output data exists in the response buffer that has not been committed, the content must be cleared before the target servlet's service method is called. If the response has been committed, an IllegalStateException must be thrown. Yoav Shapira Millennium Research Informatics -Original Message- From: Nitschke Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 4:37 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() forgets requestUri I use RequestDispatcher.forward(path) and the original requestUri get lost. If it is suppoused to do so, is there a way to get the original requestUri after the forward? Mit freundlichen Grüßen Michael Nitschke MBI Institut für Marketingberatung AG Hietzinger Hauptstraße 119-121 A-1130 Wien tel +43 (1) 8777474 9710 fax +43 (1) 8777474 9712 e-mail [EMAIL PROTECTED] www.mbi.co.at Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden. Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() forgets requestUri
But in the API is written that this Abbributes are reset between requests. (Interface ServletRequest.setAttribute()) And if I use the names you provided below the values get overwritten with the values from the requestDispatcher. Isn't it supposed that the RequestDispatcher forwards the Request as it was the initial request from the client? mfg Michael Nitschke -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 2:57 PM To: Tomcat Users List Subject: RE: RequestDispatcher.forward() forgets requestUri Hi, I strongly suggest (to anyone on the list not having done so) reading the Servlet Specification: SRV.8.3.1 Included Request Parameters Except for servlets obtained by using the getNamedDispatcher method, a servlet that has been invoked by another servlet using the include method of RequestDispatcher has access to the path by which it was invoked. The following request attributes must be set: javax.servlet.include.request_uri javax.servlet.include.context_path javax.servlet.include.servlet_path javax.servlet.include.path_info javax.servlet.include.query_string These attributes are accessible from the included servlet via the getAttribute method on the request object and their values must be equal to the request URI, context path, servlet path, path info, and query string of the included servlet, respectively. If the request is subsequently included, these attributes are replaced for that include. If the included servlet was obtained by using the getNamedDispatcher method, these attributes must not be set. SRV.8.4 The Forward Method The forward method of the RequestDispatcher interface may be called by the calling servlet only when no output has been committed to the client. If output data exists in the response buffer that has not been committed, the content must be cleared before the target servlet's service method is called. If the response has been committed, an IllegalStateException must be thrown. Yoav Shapira Millennium Research Informatics -Original Message- From: Nitschke Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 4:37 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() forgets requestUri I use RequestDispatcher.forward(path) and the original requestUri get lost. If it is suppoused to do so, is there a way to get the original requestUri after the forward? Mit freundlichen Grüßen Michael Nitschke MBI Institut für Marketingberatung AG Hietzinger Hauptstraße 119-121 A-1130 Wien tel +43 (1) 8777474 9710 fax +43 (1) 8777474 9712 e-mail [EMAIL PROTECTED] www.mbi.co.at Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden. Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() forgets requestUri
Hi, Isn't it supposed that the RequestDispatcher forwards the Request as it was the initial request from the client? No: that's one key distinction between the RequestDispatcher and HttpServletResponse#sendRedirect. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() forgets requestUri
Im using the Invokerservlet. mfg Michael Nitschke -Original Message- From: Nitschke Michael Sent: Tuesday, May 25, 2004 3:54 PM To: Tomcat Users List Subject: RE: RequestDispatcher.forward() forgets requestUri But in the API is written that this Abbributes are reset between requests. (Interface ServletRequest.setAttribute()) And if I use the names you provided below the values get overwritten with the values from the requestDispatcher. Isn't it supposed that the RequestDispatcher forwards the Request as it was the initial request from the client? mfg Michael Nitschke -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 2:57 PM To: Tomcat Users List Subject: RE: RequestDispatcher.forward() forgets requestUri Hi, I strongly suggest (to anyone on the list not having done so) reading the Servlet Specification: SRV.8.3.1 Included Request Parameters Except for servlets obtained by using the getNamedDispatcher method, a servlet that has been invoked by another servlet using the include method of RequestDispatcher has access to the path by which it was invoked. The following request attributes must be set: javax.servlet.include.request_uri javax.servlet.include.context_path javax.servlet.include.servlet_path javax.servlet.include.path_info javax.servlet.include.query_string These attributes are accessible from the included servlet via the getAttribute method on the request object and their values must be equal to the request URI, context path, servlet path, path info, and query string of the included servlet, respectively. If the request is subsequently included, these attributes are replaced for that include. If the included servlet was obtained by using the getNamedDispatcher method, these attributes must not be set. SRV.8.4 The Forward Method The forward method of the RequestDispatcher interface may be called by the calling servlet only when no output has been committed to the client. If output data exists in the response buffer that has not been committed, the content must be cleared before the target servlet's service method is called. If the response has been committed, an IllegalStateException must be thrown. Yoav Shapira Millennium Research Informatics -Original Message- From: Nitschke Michael [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 4:37 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() forgets requestUri I use RequestDispatcher.forward(path) and the original requestUri get lost. If it is suppoused to do so, is there a way to get the original requestUri after the forward? Mit freundlichen Grüßen Michael Nitschke MBI Institut für Marketingberatung AG Hietzinger Hauptstraße 119-121 A-1130 Wien tel +43 (1) 8777474 9710 fax +43 (1) 8777474 9712 e-mail [EMAIL PROTECTED] www.mbi.co.at Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden. Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward to cgi?
Tim, Now that I look at them closely I see that most of them are due to a looping problem in my program. So it just logs over and over that it's forwarding the request. I'll investigate to see if the loop is due to an error in my progamming (certainly possible since I've had to tinker with a very large controller servlet in order to incorporate this cgi page) or due to a failure in forwarding. What I was hoping in asking the question though was to find out whether anyone had done this successfully or not. I'm happy to troubleshoot the problem if I think there's a chance of success. But I hate to spend the time on it if I'm just trying to do the impossible or the dumb. Ken -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 9:21 PM To: Tomcat Users List Subject: Re: RequestDispatcher.forward to cgi? Just curious ... what are the errors? -Tim Januski, Ken wrote: I've finally managed to get cgi working in Tomcat. Now I need to forward from a servlet to a cgi page. But both RequestDispatcher.forward and RequestDispatcher.include are failing. I'm not surprised that include does but I thought it might be possible with forward. Since this is part of a large application that keeps track of the session I'd like to be able to include the cgi page in the application. But I'm beginning to think that's not possible. So I wonder if anyone knows whether it's possible to forward to a cgi page within the same Tomcat webapp. If not I'll save myself a lot of trouble and just make it a separate webapp with just a cgi component. Thanks for any advice. Ken P.S. I'm using cgi with perl because I can't find a class to add IPTC information to a Jpg and I don't have time to write it myself. Such a module does already exist in Perl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward to cgi?
I would think that the CGI servlet would work on a forward but you must be sure that: 1) No input streams were open (or that they are compatible with the CGIServlet) 2) On a POST, you do not call or look at request parameters or the input stream since it looks like the CGIServlet wants to pass the Inputstream right to the servlet. 3) I am unsure of how the CGI servlet goes to look for the exe with respect to a forward. (But I think you should be ok) -Tim Januski, Ken wrote: Tim, Now that I look at them closely I see that most of them are due to a looping problem in my program. So it just logs over and over that it's forwarding the request. I'll investigate to see if the loop is due to an error in my progamming (certainly possible since I've had to tinker with a very large controller servlet in order to incorporate this cgi page) or due to a failure in forwarding. What I was hoping in asking the question though was to find out whether anyone had done this successfully or not. I'm happy to troubleshoot the problem if I think there's a chance of success. But I hate to spend the time on it if I'm just trying to do the impossible or the dumb. Ken -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 9:21 PM To: Tomcat Users List Subject: Re: RequestDispatcher.forward to cgi? Just curious ... what are the errors? -Tim Januski, Ken wrote: I've finally managed to get cgi working in Tomcat. Now I need to forward from a servlet to a cgi page. But both RequestDispatcher.forward and RequestDispatcher.include are failing. I'm not surprised that include does but I thought it might be possible with forward. Since this is part of a large application that keeps track of the session I'd like to be able to include the cgi page in the application. But I'm beginning to think that's not possible. So I wonder if anyone knows whether it's possible to forward to a cgi page within the same Tomcat webapp. If not I'll save myself a lot of trouble and just make it a separate webapp with just a cgi component. Thanks for any advice. Ken P.S. I'm using cgi with perl because I can't find a class to add IPTC information to a Jpg and I don't have time to write it myself. Such a module does already exist in Perl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RequestDispatcher.forward to cgi?
Thanks Tim, I'll keep working on it then and see where it gets me. Ken -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2003 12:54 PM To: Tomcat Users List Subject: Re: RequestDispatcher.forward to cgi? I would think that the CGI servlet would work on a forward but you must be sure that: 1) No input streams were open (or that they are compatible with the CGIServlet) 2) On a POST, you do not call or look at request parameters or the input stream since it looks like the CGIServlet wants to pass the Inputstream right to the servlet. 3) I am unsure of how the CGI servlet goes to look for the exe with respect to a forward. (But I think you should be ok) -Tim Januski, Ken wrote: Tim, Now that I look at them closely I see that most of them are due to a looping problem in my program. So it just logs over and over that it's forwarding the request. I'll investigate to see if the loop is due to an error in my progamming (certainly possible since I've had to tinker with a very large controller servlet in order to incorporate this cgi page) or due to a failure in forwarding. What I was hoping in asking the question though was to find out whether anyone had done this successfully or not. I'm happy to troubleshoot the problem if I think there's a chance of success. But I hate to spend the time on it if I'm just trying to do the impossible or the dumb. Ken -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 9:21 PM To: Tomcat Users List Subject: Re: RequestDispatcher.forward to cgi? Just curious ... what are the errors? -Tim Januski, Ken wrote: I've finally managed to get cgi working in Tomcat. Now I need to forward from a servlet to a cgi page. But both RequestDispatcher.forward and RequestDispatcher.include are failing. I'm not surprised that include does but I thought it might be possible with forward. Since this is part of a large application that keeps track of the session I'd like to be able to include the cgi page in the application. But I'm beginning to think that's not possible. So I wonder if anyone knows whether it's possible to forward to a cgi page within the same Tomcat webapp. If not I'll save myself a lot of trouble and just make it a separate webapp with just a cgi component. Thanks for any advice. Ken P.S. I'm using cgi with perl because I can't find a class to add IPTC information to a Jpg and I don't have time to write it myself. Such a module does already exist in Perl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward to cgi?
Just curious ... what are the errors? -Tim Januski, Ken wrote: I've finally managed to get cgi working in Tomcat. Now I need to forward from a servlet to a cgi page. But both RequestDispatcher.forward and RequestDispatcher.include are failing. I'm not surprised that include does but I thought it might be possible with forward. Since this is part of a large application that keeps track of the session I'd like to be able to include the cgi page in the application. But I'm beginning to think that's not possible. So I wonder if anyone knows whether it's possible to forward to a cgi page within the same Tomcat webapp. If not I'll save myself a lot of trouble and just make it a separate webapp with just a cgi component. Thanks for any advice. Ken P.S. I'm using cgi with perl because I can't find a class to add IPTC information to a Jpg and I don't have time to write it myself. Such a module does already exist in Perl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDispatcher.forward() and filters
At 06:46 AM 12/11/01, you wrote: On Sat, 10 Nov 2001, Matt Egyhazy wrote: i have seen very, very, very bad code written for applications that use jsp. You should see some of the horrible servlet-based code I've also had to look at. People that are bound and determined to shoot themselves in the foot no matter what tools you give them. :-) Sheesh! You guys are NO FUN! Am I the only person around here that likes perl and regex for just that reason??? Where's the fun in programming if you can't hack every now and then? (And screw the maintenance guys!) -- * Jim Cheesman * Trabajo: [EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 Cooperation can only be reached if we work together. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: RequestDispatcher.forward() ?
Could somebody tell me if this behavior by design and if so why: The following fragment forwards a request to main application page: //--- String main = /index.jsp; //String main = /; RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(main); dispatcher.forward(req, resp); //--- Forwarding works on server side if code being executed as shown (main is /index.jsp) so client isn't aware about it. However, if main is set to be / (commented line above), 302 is sent to the client, so it's not a server-side redirect, right? In this case response Location header is set to http://host/pathtowebapp/index.jsp. Am I missing something? Tomcat was able to find out that index.jsp is a welcome file but nonetheless it's a client side redirect. Not a big problem of course, just curious... You have to be clear about what you mean when you say forward. There is send a redirect or get a RequestDispatcher, which are different things. What the fragment above does is it tries to forward to a servlet which is the resources associated with /. That doesn't exist so it sends an error. If you want to send something to the client you need to use response.sendRedirect() I believe. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: RequestDispatcher.forward() ?
On Sun, 11 Nov 2001, Vladimir Grishchenko wrote: Date: Sun, 11 Nov 2001 18:30:37 -0800 From: Vladimir Grishchenko [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() ? Hi there, Could somebody tell me if this behavior by design and if so why: The following fragment forwards a request to main application page: //--- String main = /index.jsp; //String main = /; RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(main); dispatcher.forward(req, resp); //--- Forwarding works on server side if code being executed as shown (main is /index.jsp) so client isn't aware about it. However, if main is set to be / (commented line above), 302 is sent to the client, so it's not a server-side redirect, right? In this case response Location header is set to http://host/pathtowebapp/index.jsp. Am I missing something? Tomcat was able to find out that index.jsp is a welcome file but nonetheless it's a client side redirect. Not a big problem of course, just curious... The reason has to do with how Tomcat happens to implement things. Let's walk through what is really happening to make sense of it: * You ask for a dispatcher for path /. * Tomcat resolves this to the default file-serving servlet (unless you have done something really strange to your configuration). * The default file-serving servlet treats a path of / as a request for the appropriate welcome file for this web application, so it looks up the right path and issues an HTTP redirect (302). Try a request dispatcher for /index.html (or /index.jsp, or whatever is appropriate for your application), and you will find that it's all done on the server side. The / path will explicitly ask for a redirect, which is why you are seeing one. regards, Vlad. Craig McClanahan -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: RequestDispatcher.forward()?
Or, more specifically: http://java.sun.com/j2ee/tutorial/api/index.html You'll find RequestDispatcher in the All Classes frame. -Original Message- From: Rob S. [mailto:[EMAIL PROTECTED]] Sent: Friday, August 24, 2001 7:55 AM To: [EMAIL PROTECTED] Subject: Re: RequestDispatcher.forward()? Can you please explain to me how to use RequestDispatcher.forward()? Yikes... you're better off searching Google or picking up a book on servlets. Or heck, you could read the servlet api javadoc comments =) - r
Re: RequestDispatcher.forward()?
Can you please explain to me how to use RequestDispatcher.forward()? Yikes... you're better off searching Google or picking up a book on servlets. Or heck, you could read the servlet api javadoc comments =) - r
Re: RequestDispatcher.forward()
thank you all for suggestions and help!
special thanks to jeff, Http(s)Message works fine for
me and solves my problem.
basti
Jeff Kilbride wrote:
Check out the HttpMessage and HttpsMessage classes in the
com.oreilly.servlet package available from Jason Hunter at www.servlets.com.
Does the same basic connection stuff and returns an InputStream which you
can wrap in a BufferedReader like Eric does below. The nice thing is that it
does secure ssl (https) connections also with the JSSE jar files -- and it's
very easy to setup and use.
Thanks,
--jeff
- Original Message -
From: Eric Lubin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 18, 2001 8:58 AM
Subject: Re: RequestDispatcher.forward()
package com.ibm.servconn;
import java.net.*;
import java.io.*;
import java.util.*;
import com.ibm.aurora.*;
public class URLForward {
private String theURL;
private String method;
public URLForward( String theURL ) {
this(theURL,POST);
}
public URLForward( String theURL, String method ) {
this.theURL = theURL;
this.method = method;
}
public String[] execute() throws BehaviorException {
Vector v = new Vector();
try {
URL theServlet = new URL(theURL);
// establish a connection with the server, but do not connect to
the servlet yet
HttpURLConnection theConnection
= (HttpURLConnection)theServlet.openConnection();
theConnection.setRequestMethod(method);
// now we can connect to the page
theConnection.connect();
// read the results from the servlet as a String
BufferedReader in = new BufferedReader(new
InputStreamReader(theConnection.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null) {
v.addElement(inputLine);
}
in.close();
String da[] = new String[v.size()];
v.copyInto(da);
return da;
}
// have to handle these somehow
catch( MalformedURLException mue ) {
throw new BehaviorException(Malformed URL
address,ServConnBhvrErrors.MALFORMED_URL,mue);
}
catch( IOException ioe ) {
throw new BehaviorException(IOException - the translator might
be
down,ServConnBhvrErrors.CANT_CONNECT_TO_SERVER,ioe);
}
}
}
Eric Lubin
T/L 443-6954 External: 561-443-6954
Notes ID: elubin@ibmusm20External: [EMAIL PROTECTED]
Sebastian Schulz [EMAIL PROTECTED] on 05/18/2001
10:58:33 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RequestDispatcher.forward()
hi,
has somebody a work-around to produce the
same behavior as if RequestDispatcher.forward()
would work with absolute URL's?
tanks in advance!
basti
RE: RequestDispatcher.forward()
are you shobhit sati from india? sorry if I am wrong Raj -Original Message- From: Sebastian Schulz [mailto:[EMAIL PROTECTED]] Sent: Friday, May 18, 2001 2:24 PM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() hi! my problem is, that i have a 'virtual' url that is a servlet, and a mapping from that virtual url to a 'real' url outside of the servletcontext. i want the user never to use or bookmark the 'real' url but allways the 'virtual'. the .forward()-method would be a cool solution to manage this, but unfortunately the 'real' urls are not in the context, and forward() doesn`t work with absolute urls. if i use sendRedirect() instead, the user sees the 'real' url, and thats bad for my application. is there a possibility to approach the desired behavior (allways 'virtual' urls)? i would be delighted to get some suggestions, tricks ... many thanks in advance! basti
Re: RequestDispatcher.forward()
??? are you shobhit sati from india? sorry if I am wrong no ;-) basti
RE: RequestDispatcher.forward()
Title: RE: RequestDispatcher.forward() ServletContext.getRequestDispatcher(java.lang.String path) takes absolute path beginign with / though the path must be relative to the current context. You will have to use getContext(java.lang.String uripath) to get a foreign Context and then use this to get the Request Dispatcher for other context 's Thanks and Regards, === Gary Grewal -Original Message- From: Sebastian Schulz [mailto:[EMAIL PROTECTED]] Sent: Friday, May 18, 2001 9:59 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() hi, has somebody a work-around to produce the same behavior as if RequestDispatcher.forward() would work with absolute URL's? tanks in advance! basti
Re: RequestDispatcher.forward()
package com.ibm.servconn;
import java.net.*;
import java.io.*;
import java.util.*;
import com.ibm.aurora.*;
public class URLForward {
private String theURL;
private String method;
public URLForward( String theURL ) {
this(theURL,POST);
}
public URLForward( String theURL, String method ) {
this.theURL = theURL;
this.method = method;
}
public String[] execute() throws BehaviorException {
Vector v = new Vector();
try {
URL theServlet = new URL(theURL);
// establish a connection with the server, but do not connect to
the servlet yet
HttpURLConnection theConnection
= (HttpURLConnection)theServlet.openConnection();
theConnection.setRequestMethod(method);
// now we can connect to the page
theConnection.connect();
// read the results from the servlet as a String
BufferedReader in = new BufferedReader(new
InputStreamReader(theConnection.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null) {
v.addElement(inputLine);
}
in.close();
String da[] = new String[v.size()];
v.copyInto(da);
return da;
}
// have to handle these somehow
catch( MalformedURLException mue ) {
throw new BehaviorException(Malformed URL
address,ServConnBhvrErrors.MALFORMED_URL,mue);
}
catch( IOException ioe ) {
throw new BehaviorException(IOException - the translator might be
down,ServConnBhvrErrors.CANT_CONNECT_TO_SERVER,ioe);
}
}
}
Eric Lubin
T/L 443-6954 External: 561-443-6954
Notes ID: elubin@ibmusm20External: [EMAIL PROTECTED]
Sebastian Schulz [EMAIL PROTECTED] on 05/18/2001
10:58:33 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RequestDispatcher.forward()
hi,
has somebody a work-around to produce the
same behavior as if RequestDispatcher.forward()
would work with absolute URL's?
tanks in advance!
basti
Re: RequestDispatcher.forward()
Check out the HttpMessage and HttpsMessage classes in the
com.oreilly.servlet package available from Jason Hunter at www.servlets.com.
Does the same basic connection stuff and returns an InputStream which you
can wrap in a BufferedReader like Eric does below. The nice thing is that it
does secure ssl (https) connections also with the JSSE jar files -- and it's
very easy to setup and use.
Thanks,
--jeff
- Original Message -
From: Eric Lubin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 18, 2001 8:58 AM
Subject: Re: RequestDispatcher.forward()
package com.ibm.servconn;
import java.net.*;
import java.io.*;
import java.util.*;
import com.ibm.aurora.*;
public class URLForward {
private String theURL;
private String method;
public URLForward( String theURL ) {
this(theURL,POST);
}
public URLForward( String theURL, String method ) {
this.theURL = theURL;
this.method = method;
}
public String[] execute() throws BehaviorException {
Vector v = new Vector();
try {
URL theServlet = new URL(theURL);
// establish a connection with the server, but do not connect to
the servlet yet
HttpURLConnection theConnection
= (HttpURLConnection)theServlet.openConnection();
theConnection.setRequestMethod(method);
// now we can connect to the page
theConnection.connect();
// read the results from the servlet as a String
BufferedReader in = new BufferedReader(new
InputStreamReader(theConnection.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null) {
v.addElement(inputLine);
}
in.close();
String da[] = new String[v.size()];
v.copyInto(da);
return da;
}
// have to handle these somehow
catch( MalformedURLException mue ) {
throw new BehaviorException(Malformed URL
address,ServConnBhvrErrors.MALFORMED_URL,mue);
}
catch( IOException ioe ) {
throw new BehaviorException(IOException - the translator might
be
down,ServConnBhvrErrors.CANT_CONNECT_TO_SERVER,ioe);
}
}
}
Eric Lubin
T/L 443-6954 External: 561-443-6954
Notes ID: elubin@ibmusm20External: [EMAIL PROTECTED]
Sebastian Schulz [EMAIL PROTECTED] on 05/18/2001
10:58:33 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: RequestDispatcher.forward()
hi,
has somebody a work-around to produce the
same behavior as if RequestDispatcher.forward()
would work with absolute URL's?
tanks in advance!
basti
Re: RequestDispatcher.forward()-Problem with anchors
thank you, Rob! (thank you, Michael) ... it sounds consistent. once more again to secure, i understand it correct: a forward in opposition to a redirect is some server-internal operation, whose result is send back to the browser. as the browser itself don't realize it, the anchor at the url has not the desired effect. ok. that a redirection with a anchor-url operates, is clear. is there a trick to anyhow get some related behavior with forward to work? or is this not necessary, because i can access the original session object at the second page in the case of a redirect as well? (i think this was my error in reasoning, that i have to use a forward when using sessions) thank you again, bAs T. Rob Tanner schrieb: When you do a RequestDispatcher.forward(), that's an internal operation, and not a redirect send back to the browser. In the latter case, the browser initiates a new GET request to the new URL. In the former case, the page at the RequestDispatcher.forward() address is simply sent to the browser without the browser being any the wiser. In that sense, it's the same kind of thing as an internal redirect in Apache. Whether the address "example.jsp#position1" is a good URL or a bad URL or whether it's a tomcat bug or a serverlet 2.2 spec bug that an exception wasn't thrown is something I don't know. But going back to my first point, since the browser is unaware of the forward anyway, anchors won't work. Do a redirect to the browser instead. -- Rob --On Monday, March 05, 2001 10:09:24 AM -0800 Filip Hanik [EMAIL PROTECTED] wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher.forward()-Problem with anchors
Hi Sebastian, Sebastian Schulz wrote: is there a trick to anyhow get some related behavior with forward to work? or is this not necessary, because i can access the original session object at the second page in the case of a redirect as well? I think so. If you want to send an error, store it in the session and check it in the receiving servlet. Un saludo, Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: RequestDispatcher.forward()-Problem with anchors
I thought the anchor tag was something that was interpreted by the browser, not the server. doesn't the server just ignore those? correct me if I am wrong! Filip -Original Message- From: Sebastian Schulz [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 9:48 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward()-Problem with anchors hi, i have a problem with RequestDispatcher.forward(): if the url contains an anchor like "example.jsp#position1" then forwarding seams to be be all right (no error, exception ...), but the 'new' page has no content. i tried to forward to a url with parameters like "example.jsp?name=value", this is no problem and the page is shown correctly? whats my mistake? is it possible to forward a anchor-containing url at all? any suggestions desired! thank you all in advance, bas T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: RequestDispatcher.forward()-Problem with anchors
When you do a RequestDispatcher.forward(), that's an internal operation, and not a redirect send back to the browser. In the latter case, the browser initiates a new GET request to the new URL. In the former case, the page at the RequestDispatcher.forward() address is simply sent to the browser without the browser being any the wiser. In that sense, it's the same kind of thing as an internal redirect in Apache. Whether the address "example.jsp#position1" is a good URL or a bad URL or whether it's a tomcat bug or a serverlet 2.2 spec bug that an exception wasn't thrown is something I don't know. But going back to my first point, since the browser is unaware of the forward anyway, anchors won't work. Do a redirect to the browser instead. -- Rob --On Monday, March 05, 2001 10:09:24 AM -0800 Filip Hanik [EMAIL PROTECTED] wrote: I thought the anchor tag was something that was interpreted by the browser, not the server. doesn't the server just ignore those? correct me if I am wrong! Filip -Original Message- From: Sebastian Schulz [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 9:48 AM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward()-Problem with anchors hi, i have a problem with RequestDispatcher.forward(): if the url contains an anchor like "example.jsp#position1" then forwarding seams to be be all right (no error, exception ...), but the 'new' page has no content. i tried to forward to a url with parameters like "example.jsp?name=value", this is no problem and the page is shown correctly? whats my mistake? is it possible to forward a anchor-containing url at all? any suggestions desired! thank you all in advance, bas T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] _ _ _ _ __ _ _ _ _ /\_\_\_\_\/\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_//\/_/ /\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher.forward() problem
Andrew Kerr wrote:
Hello,
I've been having a bit of trouble with the RequestDispatcher.forward()
method. If I try to forward to a URL with a query string on it, and
then have some code that processes the forwarded request, the
getQueryString() method does not return the query string. However, the
parameters _are_ available via getParameter().
Section 8.1.1 of the Servlet 2.2 spec does not explicitly state what the
getQueryString() method should return in the event of a forward, but it
seems to me that if the new request parameters are added to the
request's internal list of parameters, that it only makes sense to also
add the parameters to the query string.
Section 8.4 of the spec states that "the path elements of the request
object reflect those of the original request." Although a query string
is not strictly considered a "path element" according to the spec, it
does seem in the spirit of section 8.4 that the additional parameters
should be on the query string.
Does anyone have any thoughts on this?
Thanks,
Andrew
Hi !
I can't answer your exact question.
But for many purposes - other than reusing an existing servlet class
that you forward to -
request.setAttribute("name" , valueObject) ;
RequestDispatcher dest = context.getRequestDispatcher("...");
dest.forward(request,response);
will do.
--
Paul Marshall
[EMAIL PROTECTED]
089/26019-609
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher.forward() problem
I met the same problem. To read your query string in included or forwarded servlet,
you have to use the call:
String query = request.getAttribute("javax.servlet.include.query_string");
Regards,
Dmitry R., [EMAIL PROTECTED]
Chief Architect, MetricStream.COM
Santa Clara, CA
-Original Message-
From:paul marshal [EMAIL PROTECTED]
Sent:Wed, 21 Feb 2001 16:48:26 +0100
To: [EMAIL PROTECTED]
Subject: Re: RequestDispatcher.forward() problem
Andrew Kerr wrote:
Hello,
I've been having a bit of trouble with the RequestDispatcher.forward()
method. If I try to forward to a URL with a query string on it, and
then have some code that processes the forwarded request, the
getQueryString() method does not return the query string. However, the
parameters _are_ available via getParameter().
Section 8.1.1 of the Servlet 2.2 spec does not explicitly state what the
getQueryString() method should return in the event of a forward, but it
seems to me that if the new request parameters are added to the
request's internal list of parameters, that it only makes sense to also
add the parameters to the query string.
Section 8.4 of the spec states that "the path elements of the request
object reflect those of the original request." Although a query string
is not strictly considered a "path element" according to the spec, it
does seem in the spirit of section 8.4 that the additional parameters
should be on the query string.
Does anyone have any thoughts on this?
Thanks,
Andrew
Hi !
I can't answer your exact question.
But for many purposes - other than reusing an existing servlet class
that you forward to -
request.setAttribute("name" , valueObject) ;
RequestDispatcher dest = context.getRequestDispatcher("...");
dest.forward(request,response);
will do.
--
Paul Marshall
[EMAIL PROTECTED]
089/26019-609
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
___
Visit http://www.visto.com/info, your free web-based communications center.
Visto.com. Life on the Dot.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher.forward() in Tomcat 3.2.1
You are right. Control does return to the calling servlet. It just couldn't write to the response. It would be nice if an exception was thrown. After control returns to the calling servlet, I try forwarding to a second servlet and that doesn't seem to work. The first servlet that was forwarded to did not change the response. Is multiple forward within a servlet not supported/allowed? Bill "Craig R. McClanahan" wrote: William Au wrote: Is there any way in Tomcat 3.2.1 for the control to return to a servlet after its call to RequestDispatcher.forward() is completed? Control *does* return -- RequestDispatcher.forward() is a normal Java method call. However, the servlet spec prohibits you from modifying the response at this point. If Weblogic lets you do this (for instance, by allowing you to add additional text to the response created by the forwarded-to servlet), then it is not obeying the spec. That is the behavior of WebLogic 5.1.0. I want my code to work on the same way running under both. I am aware of the RequestDispatcher.include() method. Bill Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() in Tomcat 3.2.1
What Craig meant (I believe) by "prohibits you from modifying the response" is that the response has been committed and no more data can be sent. The html/other-data you are sending to the client is part of the response. When the forward returns, you are prohibited by the spec, from adding any more information to the response output stream. If you need to do as you desire, you must use some kind of include based scheme instead of forward. Regards, Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 16, 2001 9:38 AM To: [EMAIL PROTECTED] Subject: Re: RequestDispatcher.forward() in Tomcat 3.2.1 You are right. Control does return to the calling servlet. It just couldn't write to the response. It would be nice if an exception was thrown. After control returns to the calling servlet, I try forwarding to a second servlet and that doesn't seem to work. The first servlet that was forwarded to did not change the response. Is multiple forward within a servlet not supported/allowed? Bill "Craig R. McClanahan" wrote: William Au wrote: Is there any way in Tomcat 3.2.1 for the control to return to a servlet after its call to RequestDispatcher.forward() is completed? Control *does* return -- RequestDispatcher.forward() is a normal Java method call. However, the servlet spec prohibits you from modifying the response at this point. If Weblogic lets you do this (for instance, by allowing you to add additional text to the response created by the forwarded-to servlet), then it is not obeying the spec. That is the behavior of WebLogic 5.1.0. I want my code to work on the same way running under both. I am aware of the RequestDispatcher.include() method. Bill Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RequestDispatcher.forward() in Tomcat 3.2.1
William Au wrote: Is there any way in Tomcat 3.2.1 for the control to return to a servlet after its call to RequestDispatcher.forward() is completed? Control *does* return -- RequestDispatcher.forward() is a normal Java method call. However, the servlet spec prohibits you from modifying the response at this point. If Weblogic lets you do this (for instance, by allowing you to add additional text to the response created by the forwarded-to servlet), then it is not obeying the spec. That is the behavior of WebLogic 5.1.0. I want my code to work on the same way running under both. I am aware of the RequestDispatcher.include() method. Bill Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: RequestDispatcher.forward() in Tomcat 3.2.1
I believe this is the normal behavior. Your servlet should regain control after the forward. At least I know it works when forwarding to JSPs. -Casey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 15, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: RequestDispatcher.forward() in Tomcat 3.2.1 Is there any way in Tomcat 3.2.1 for the control to return to a servlet after its call to RequestDispatcher.forward() is completed? That is the behavior of WebLogic 5.1.0. I want my code to work on the same way running under both. I am aware of the RequestDispatcher.include() method. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - This email server is running an evaluation copy of the MailShield anti- spam software. Please contact your email administrator if you have any questions about this message. MailShield product info: www.mailshield.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
