Thanks for the feedback and suggestions. I've decided to take a different
approach with my error handling. I think the error handling strategy I was
trying to implement was a bad idea and I have abandoned it. (In particular,
I think I was trying to do a redirect after my frameworks had done one or
more forwards. Several filters are involved as well. I tried to diagnose it
all but it became too complicated for me to unravel.)
BTW, I analyzed the behavior in Jetty and found that the client was
responding to the redirect before the original request had completed, i.e.
the handling of the redirect request was taking place in my servlet even
before the original error-causing request had completed. The debugging
statements for both requests were intermingled in my log files.
Brad
Christopher Schultz-2 wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brad,
>
> On 2/17/2009 12:32 AM, Brad Whitaker wrote:
>> try {
>>
>> if(LOG.isDebugEnabled()) {
>> LOG.debug("Executing redirect with response
>> ["+response+"]");
>> }
>> String redirectUrl = response.encodeRedirectURL(actualUri);
>> response.sendRedirect(redirectUrl);
>>
>> } catch (IOException e) {
>> throw new ControllerExecutionException("Error redirecting
>> request for url ["+actualUri +"]: " + e.getMessage(),e);
>> } catch (Exception ex) {
>> LOG.error("redirectResponse: caught Exception=" + ex);
>> throw new ControllerExecutionException("Error redirecting
>> request for url [" + actualUri + "]: " + ex.getMessage(), ex);
>> }
>> return null;
>
> This should totally work.
>
>> I'm certain that the redirect is never sent to the browser. I've been
>> using
>> Firebug and HttpWatch to monitor each request and response. When I
>> execute
>> this code on Jetty I do see the redirect sent to the browser.
>
> How do you know that no exceptions are being thrown?
>
>> I took a look at the Error Handling sections of the Servlet spec and it
>> wasn't clear to me if perhaps the redirect is not permitted after an
>> exception has been thrown.
>
> Exceptions are orthogonal to request/response processing. If you allow
> the exception to propagate (that is, you don't catch it), then Tomcat
> typically sends a 500 Server Error response to the client. There is no
> requirement for exception handling in the servlet spec (other than those
> implied by the API itself) and no reason a "regular" response can't be
> given even in an exceptional condition.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmcXiIACgkQ9CaO5/Lv0PArfQCdFhJqH2nEPLirJrjfo8+P7Efk
> V/IAnRFdu9dTlMd7B/m3zlut1Xk7Ej5t
> =Mb/0
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/HttpServletResponse.sendRedirect%28%29-not-working--tp22049004p22090697.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
