From tomcat-dev-return-15645-qmlist-jakarta-archive-tomcat-dev=jakarta.apache.org@jakarta.apache.org Thu Aug 01 18:31:23 2002 Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 24508 invoked from network); 1 Aug 2002 18:31:23 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Aug 2002 18:31:23 -0000 Received: (qmail 28698 invoked by uid 97); 1 Aug 2002 18:31:39 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 28669 invoked by uid 97); 1 Aug 2002 18:31:38 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 28655 invoked by uid 50); 1 Aug 2002 18:31:37 -0000 Date: 1 Aug 2002 18:31:37 -0000 Message-ID: <20020801183137.28654.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 7227] - directive don't work X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7227 directive don't work ------- Additional Comments From coreym12065@yahoo.com 2002-08-01 18:31 ------- It should work for 500 errors if you explicitly call response.sendError(500), however if an exception is allowed to propogate to container, it does not work. There was another bug filed for this, however it was closed because one can interpret the Servlet spec 2.3 to mean that the current behavior is acceptable. Because there seem to be so many user questions about this, I don't think users expect the server to respond the way it does. Re-routing on 'Exception' doesn't work either, because it won't allow you to handle specific Exceptions differently (NullPointerExceptions going to one page, ClassNotFoundException going to another, etc.). All Exceptions that are thrown will be picked up by the 'Exception' error page. I've done some digging, and a fix for this is pretty simple. In the ErrorDispatcherValve.throwable(request, response, throwable) method, it attempts to get the error page location by the type of the throwable (and if throwable is a ServletException, by testing against the root cause). If neither of these match a registered error page, it then quits. What I think it's safe to assume here is that we should then look to see if the user has registered an error page to the error code 500. It ends up setting it to 500 later anyway, and this way, at least we can handle it properly. The code is simple: if(errorPage == null) { errorPage = context.findErrorPage(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); } ... and it even works... Now can someone give me some tips about how to get this fix in? -- To unsubscribe, e-mail: For additional commands, e-mail: