Announcement Announcement Module
Collapse
No announcement yet.
Spring MVC, Sitemesh & Tomcat - error view not rendered Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring MVC, Sitemesh & Tomcat - error view not rendered

    Hi all,

    I'm hoping someone can help. I've been looking at this for two days, and I've come to a dead end...

    I'm running a Spring 2.5.5 web app on Tomcat 5.5 with Sitemesh 2.4.1. I have a Spring SimpleMappingExceptionResolver configured, which catches exceptions and forwards to an 'error' view, pointing to error.jsp. This generally functions as expected, and the output of error.jsp is wrapped by my Sitemesh decorator.

    However, if I reduce the number of characters in error.jsp, the view is no longer rendered correctly and is, instead, replaced by the standard Tomcat error 500 page, and stack trace. I've stepped through the code at length, and it seems my generated response is being overwritten with the Tomcat error page in the catalina ErrorReportValve class.

    The DispatcherServlet puts the exception on the request under the standard catalina.GLOBALS key. ErrorReportValve then looks up this Exception, but it also checks Response.isCommitted(), and outputs its own error page if this is false. I've done some testing with various jsps, and it seems that isCommitted() returns true for the larger jsps, and false for the smaller jsps.

    (Still with me, hopefully?)

    So, having stepped through the rendering code, it seems that setCommitted() is only called if the parser reaches the end of the buffer in JspWriterImpl.write(), in which case 'flushBuffer()' is called. This sets the response as committed.

    There, afaics, two possibilities here:

    1. Sitemesh is failing to set the response to 'committed'.

    2. The exception should be removed from the request once dealt with.

    I've removed Sitemesh and run the tests and it works correctly - the exception is still on the request and the response is committed, so I'm guessing that my issue is (1), above.

    So, any thoughts on how I can proceed from here? Can someone confirm that the exception is supposed to remain on the request? (I had a philosophical conversation with a colleague who felt that if it's dealt with by the framework, the servlet container should never even know about it.)

    Thanks for reading, and please let me know if I can provide any more information, as I'm stuck as to how to proceed!
Working...
X