struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (WW-733) Unmapped action results in a Server 500 error on Tomcat 5.x
Date Fri, 09 Jun 2006 05:59:16 GMT
     [ 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


Mime
View raw message