[ http://issues.apache.org/struts/browse/WW-733?page=comments#action_38582 ] Przemek Dyk commented on WW-733: --------------------------------
Tomcat 5.5.16 struts.devMode = false http://localhost:8080/struts2-blank-2.0.1/example/blah.action returns 404 but http://localhost:8080/struts2-blank-2.0.1/blah.action returns 500 There is no Action mapped for namespace / and action name blah. - [unknown location] com.opensymphony.xwork2.DefaultActionProxy.<init>(DefaultActionProxy.java:75) org.apache.struts2.impl.StrutsActionProxy.<init>(StrutsActionProxy.java:18) org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:20) org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:320) org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:256) > 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 2 > Issue Type: Bug > Components: Dispatch > Affects Versions: WW 2.1.7 > Environment: Windows XP, Tomcat 5.0.30 (also tested on Tomcat 5.5) > Reporter: Erik Pilz > Assigned To: Don Brown > Fix For: 2.0.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
