You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Don Brown (JIRA)" <ji...@apache.org> on 2006/06/09 07:59:16 UTC
[jira] Resolved: (WW-733) Unmapped action results in a Server 500
error on Tomcat 5.x
[ http://issues.apache.org/struts/browse/WW-733?page=all ]
Don Brown resolved WW-733:
--------------------------
Resolution: Cannot Reproduce
Assign To: Don Brown (was: Rainer Hermanns)
I don't think this is an issue anymore, as we are just returning a 404 without any exception. The correct 404 page is shown in Jetty using QuickStart. Please reopen if the 500 persists in Tomcat. Thanks.
> Unmapped action results in a Server 500 error on Tomcat 5.x
> -----------------------------------------------------------
>
> Key: WW-733
> URL: http://issues.apache.org/struts/browse/WW-733
> Project: Struts Action 2
> Type: Bug
> Components: Dispatch
> Versions: WW 2.1.7
> Environment: Windows XP, Tomcat 5.0.30 (also tested on Tomcat 5.5)
> Reporter: Erik Pilz
> Assignee: Don Brown
> Fix For: 2.0
>
> Browsing to an unmapped action results in a Server 500 error on Tomcat 5.x.
> Steps to reproduce:
> 1. Add webwork-example.war to a new installation of Tomcat 5.x.
> 2. Start the application and browse to http://localhost:8080/webwork-example/blah.action.
> Expected result:
> An HTTP status code of 404 and to be forwarded to the 404 error page.
> Actual result:
> HTTP status code of 500 and forwarded to the 500 error page.
> To verify that the behavior is specific to Tomcat, I loaded webwork-example.war onto Resin 3.0.10. Browsing to http://localhost:8080/webwork-example/blah.action produces the expected result (404). I have not tested this with any other application servers.
> I was able to isolate the problem and found that it is caused by setting the exception attributes in the sendError() method in com.opensymphony.webwork.dispatcher.ServletDispatcher. Apparently setting the request attribute javax.servlet.error.exception or javax.servlet.jsp.jspException will cause Tomcat to later change the status code to HttpServletResponse.SC_INTERNAL_SERVER_ERROR (500). I stepped through the ServletDispatcher code in a debugger and found that the status code is set to 404 before the service() method returns so the status change must occur somewhere in Tomcat.
> I don?t know much about Tomcat internals, but I think the issue can be traced to org.apache.catalina.core.StandardHostValve. After the request has been processed, there?s a test for javax.servlet.error.exception. If a Throwable object exists, it is processed by a method called throwable() that sets several attributes and finds the error page to forward to. In this method the status code is set to HttpServletResponse.SC_INTERNAL_SERVER_ERROR (500).
> I couldn't find anything in the Servlet 2.4 spec that describes the usage of javax.servlet.error.exception so I don't know if this is a Tomcat issue or a WebWork issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira