Tomcat overrides Spring 2.5.5 and ExceptionResolvers

Hi,
it took me quite long to debug through the tomcat sources to find out, why my exceptionresolver is not working anymore (in one special case).

In Spring 2.5.5 there was added a functionality in org.springframework.web.util.WebUtils to expose the Exception as the servletspec 2.3 attributes (javax.servlet.error.exception)

Tomcat looks for this attribute and shows the tomcat error page.
Because of this our custom ExceptionResolver doesn't work anymore.
This Resolver returns a redirect view. Because the redirect view is not commiting the response the ErrorReportValve from tomcat sets its own errorpage.

This only happens because Spring is exposing the exception as the standard Attributs and after the redirectView the Response is not commited. So ErrorReportValve from tomcat is setting the errorstatus to 500 and puts its own errorpage in the response.

I guess i'm doing something wrong, because it seems stupid to have the ExceptionResolver mechanism being totally defeated (if the view is not commiting the response) in tomcat 6 since Spring 2.5.5.

So i'm wondering what to do?
As a workaround it would be nice to know how to commit the response manually? But a correct solution would be much nicer.


EDIT: after digging into it, this seems to be a problem in tomcat, cause the servletspec says, after sendRedirect the response should be considered commited. i guess i will look into this at the tomcat mailing lists too.

regards
Christian

ok i found a workaround.
i use a custom view which cleans the request from all the error attributes which are set in the WebUtils#exposeErrorRequestAttributes(...) method.
That way tomcat won't pick 'em up and override my redirect.
this works, because the exposure of the request attributes happens before evaluation the view which comes from the exceptionresolver.


works. not perfect but working.

This is already a known issue and is fixed in spring 2.5.6, so try the latest nightly build and it should work correctly.

hi,
thx for the answer
found the bug report for all other interested people jira.springframework.org/browse/SPR-4973