Re: HttpServletResponse.sendRedirect() not working?
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
Re: HttpServletResponse.sendRedirect() not working?
There's a lot of processing after the sendRedirect(). The sendRedirect() is
contained in Grails platform code and I confess that I don't fully
understand the motivation behind all of the processing. The sendRedirect()
has occurred after an application defined exception has been thrown. A
Spring exception resolver has forwarded the request after the exception has
been thrown. sendRedirect() occurs after the forward.
Here is the code that sends the redirect. It is Grails code except that I
added some of the verbose logging statements and the "catch (Exception ex)"
just to be sure I wasn't missing an exception:
private Object redirectResponse(String actualUri, HttpServletResponse
response) {
if(LOG.isDebugEnabled()) {
LOG.debug("Dynamic method [redirect] forwarding request to
["+actualUri +"]");
}
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;
}
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.
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.
Any suggestions would be appreciated.
Qiao Jin wrote:
>
> What's after the sendRedirect() call in your code? And what's in the
> final?
> Can you post a simple code sample that would demonstrate the problem?
>
> On Mon, Feb 16, 2009 at 5:55 PM, Brad Whitaker wrote:
>
>>
>> I'm having a problem with Tomcat 6.0.18 that I don't understand. I'm
>> invoking
>> HttpServletResponse.sendRedirect() but no redirect is being sent to the
>> browser. Is there a valid reason why this might occur, or is this likley
>> a
>> bug in Tomcat?
>>
>> My code has thrown an exception prior to invoking the redirect but I
>> can't
>> find anything in the Servlet spec that would indicate this is a problem.
>> The
>> HttpServletResponse.sendRedirect() is within a try/catch block and no
>> exception is being thrown in response to sendRedirect(). My app is built
>> on
>> Grails (which in turn is built on top of Spring) and I don't fully
>> understand the exception resolution process used by my frameworks, but I
>> have verified that sendRedirect() is being executed and not throwing an
>> exception. This same code is working as desired when executed on Jetty
>> (i.e.
>> the desired redirect is received by the browser) but when executed in
>> Tomcat
>> I see the default Tomcat error page displayed rather than the redirect.
>>
>> Any advice or suggestions would be appreciated.
>> --
>> View this message in context:
>> http://www.nabble.com/HttpServletResponse.sendRedirect%28%29-not-working--tp22049004p22049004.html
>
>
>
--
View this message in context:
http://www.nabble.com/HttpServletResponse.sendRedirect%28%29-not-working--tp22049004p22051065.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
HttpServletResponse.sendRedirect() not working?
I'm having a problem with Tomcat 6.0.18 that I don't understand. I'm invoking HttpServletResponse.sendRedirect() but no redirect is being sent to the browser. Is there a valid reason why this might occur, or is this likley a bug in Tomcat? My code has thrown an exception prior to invoking the redirect but I can't find anything in the Servlet spec that would indicate this is a problem. The HttpServletResponse.sendRedirect() is within a try/catch block and no exception is being thrown in response to sendRedirect(). My app is built on Grails (which in turn is built on top of Spring) and I don't fully understand the exception resolution process used by my frameworks, but I have verified that sendRedirect() is being executed and not throwing an exception. This same code is working as desired when executed on Jetty (i.e. the desired redirect is received by the browser) but when executed in Tomcat I see the default Tomcat error page displayed rather than the redirect. Any advice or suggestions would be appreciated. -- View this message in context: http://www.nabble.com/HttpServletResponse.sendRedirect%28%29-not-working--tp22049004p22049004.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
Re: filter debugging or logging?
Thanks for the response. I wanted to know about the order primarily because I
thought I might be having a problem with configuration, i.e. I
was concerned that some filters might or might not be firing on ERROR and
REDIRECT. I've done enough debugging at this point to determine this is not
my problem. (My problem seems to be that Tomcat 6 is not sending a redirect
when I invoke HttpServletResponse.sendRedirect(redirectUrl) but I'll put
that in a separate topic.)
Christopher Schultz-2 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brad,
>
> On 2/13/2009 7:34 PM, Brad Whitaker wrote:
>> Is there a logger that can emit information about when servlet filters
>> are
>> invoked?
>
> Not a logger per-se, but there is an internal event fired and can
> presumably be listened-to. See the source for
> java/org/apache/catalina/core/ApplicationFilterChain.java, specifically
> the internalDoFilter method. You can see these two events reported:
>
>
> support.fireInstanceEvent(InstanceEvent.BEFORE_FILTER_EVENT,
> filter, request, response);
>
> ...
>
>
> support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
> filter, request, response);
>
>
> I'm not sure what the best way is to listen to these events.
> org.apache.catalina.util.InstanceSupport is the class for the 'support'
> reference above. That class has methods for registering event listeners,
> but I'm not sure what the best way is to get the instance of
> InstanceSupport that is being used by Tomcat. JMX might work to grab
> that object from Tomcat.
>
>> I have multiple filters
>> that have been provided by 3rd party libraries and it is very difficult
>> to
>> know when they are invoked, and in what order.
>
> They should be invoked in the order in which they are declared in
> web.xml. Is this not the behavior you are observing? What version of
> Tomcat are you running?
>
>> I'd primarily
>> like to know when doFilter() is invoked (along with the name of the
>> filter).
>> I think this would be enough to follow the chains.
>
> You could write a trivial filter that does something like this:
>
> public class OrderingFilter
> implements Filter
> {
>private String _name;
>public void init(FilterConfig config)
>{
> _name = config.getInitParameter("name");
>}
>
>public void doFilter(ServletRequest request,
> ServletResponse response,
> FilterChain chain)
> throws IOException, ServletException
>{
>System.out.println("Running " + _name);
>
>chain.doFilter(request, response);
>
>System.out.println("Finished running " + _name);
>}
> }
>
> Then, configure this filter to run in between every filter you have
> configured. Something like this:
>
> Filter A
> OrderingFilter[name='after A']
> Filter B
> OrderingFilter[name='after B']
> Filter C
> OrderingFilter[name='after C']
> Filter D
> OrderingFilter[name='after D']
> Filter E
> OrderingFilter[name='after E']
> ...
>
> This gives you a crude yet non-invasive debugging mechanism. Just make
> sure that you have all your url-mappings set up to mirror those of the
> original filters.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmZ5QgACgkQ9CaO5/Lv0PDVFwCfYh9Mf0R6xUhi8gorM3sWnBgA
> D64AoL7sBsxNRh8MNSW09vfoJ70BmjJK
> =3fLv
> -END PGP SIGNATURE-
>
>
--
View this message in context:
http://www.nabble.com/filter-debugging-or-logging--tp22007573p22049002.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
filter debugging or logging?
Is there a logger that can emit information about when servlet filters are invoked? I'm having trouble with some filters and it feels like I'm completely blind and unable to see what's going on. I have multiple filters that have been provided by 3rd party libraries and it is very difficult to know when they are invoked, and in what order. I've resorted to adding log messages to some of the various 3rd party libraries and recompiling them, but this doesn't seem like the right way to go about things. I'd primarily like to know when doFilter() is invoked (along with the name of the filter). I think this would be enough to follow the chains. Thanks, Brad -- View this message in context: http://www.nabble.com/filter-debugging-or-logging--tp22007573p22007573.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
