Re: Error 500 with stack trace

The details of what your error page/servlet can expect is detailed in
section 9.9 of the Servlet specification from Sun (included below).

-Knut




SRV.9.9 Error Handling

SRV.9.9.1 Request Attributes

A web application must be able to specify that when errors occur other
resources in the application are used. The specification of these
resources is done in the deployment descriptor.

If the location of the error handler is a servlet or a JSP page, the
request attributes in Table SRV.9-1 must be set.

Table SRV.9-1 Request Attributes and their types
Request Attributes Type
javax.servlet.error.status_code java.lang.Integer
javax.servlet.error.exception_type java.lang.Class
javax.servlet.error.message java.lang.String
javax.servlet.error.exception java.lang.Throwable
javax.servlet.error.request_uri java.lang.String
javax.servlet.error.servlet_name java.lang.String

These attributes allow the servlet to generate specialized content
depending on the status code, the exception type, the error message,
the exception object propagated, and the URI of the request processed
by the servlet in which the error occurred (as determined by the
getRequestURI call), and the logical name of the servlet in which the
error occurred.

With the introduction of the exception object to the attributes list
for version 2.3 of this specification, the exception type and error
message attributes are redundant. They are retained for backwards
compatibility with earlier versions of the API.



SRV.9.9.2 Error Pages

To allow developers to customize the appearance of content returned to
a web client when a servlet generates an error, the deployment
descriptor defines a list of error page descriptions. The syntax
allows the configuration of resources to be returned by the container
either when a servlet sets a status code to indicate an error on the
reponse, or if the servlet generates an exception or error that
propogates to the container.

If a status code indicating an error is set on the response, the
container consults the list of error page declarations for the web
application that use the status-code syntax and attempts a match. If
there is a match, the container returns the resource as indicated by
the location entry.

A servlet may throw the following exceptions during processing of a
request:

• runtime exceptions or errors
• ServletExceptions or subclasses thereof
• IOExceptions or subclasses thereof

The web application may have declared error pages using the
exception-type element. In this case the container matches the
exception type by comparing the exception thrown with the list of
error-page definitions that use the exceptiontype element. A match
results in the container returning the resource indicated in the
location entry. The closest match in the class heirarchy wins.

If no error-page declaration containing an exception-type fits using
the class-heirarchy match, and the exception thrown is a
ServletException or subclass thereof, the container extracts the
wrapped exception, as defined by the ServletException.getRootCause
method. A second pass is made over the error page declarations, again
attempting the match against the error page declarations, but using
the wrapped exception instead.

Error-page declarations using the exception-type element in the
deployment descriptor must be unique up to the class name of the
exception-type. Similarly, error-page declarations using the
status-code element must be unique in the deployment descriptor up to
the status code.

The error page mechanism described does not intervene when errors
occur in servlets invoked using the RequestDispatcher. In this way, a
servlet using the RequestDispatcher to call another servlet has the
opportunity to handle errors generated in the servlet it calls.

If a servlet generates an error that is not handled by the error page
mechanism as described above, the container must ensure the status
code of the response is set to status code 500.