Setting Error Pages by Using the web.xml Template
Suppose you want to define a page to go for 404 errors that give a site search and abbreviated site map, a page to go to for java.SQL.exceptions that automatically e-mails the database administrator, or another custom error page based specifically on the type of error. The web.xml template lets you do this. Take a look at the revised web.xml template in Listing 2.
Listing 2web.xmlDefining Error Pages
<web-app> <display-name>Orange Whip Studios</display-name> <description>JRun Web Application Construction Kit Demo</description> <context-param> <param-name>CompanyName</param-name> <param-value>Orange Whip Studios</param-value> </context-param> <context-param> <param-name>Datasource</param-name> <param-value>ows</param-value> </context-param> <error-page> <error-code>404</error-code> <location>/19/404.html</location> </error-page> <error-page> <exception>java.sql.Exception</exception> <location>/19/sqlException.jsp</location> </error-page> </web-app>
Most of this file is similar to the web.xml template. However, there are a few new tags to look at. The main tags used in defining error pages are the <error-page> tags. Between <error-page> tags, you can have one of two sets of subtags. The first combination defines error pages based on Hypertext Transfer Protocol (HTTP) error types:
<error-page> <error-code>404</error-code> <location>/19/404.html</location> </error-page>
The first subtag is <error-code>. This is where you place the number of the code your error page will respond to. We are all familiar with the 404 Not Found error from trying to find Web pages that no longer exist. So, simply enter 404 between this set of tags. Next, you supply the location of the error page to use by using the <location> subtag. The path entered should be an absolute path that starts in the application root. Here, we entered //19/404.html. When the server receives a 404 error, it looks for this page instead of giving the usual JRun exception error.
Compilation errors and Java exceptions are always 500 Internal Server errors. By defining an error page for this error type on your production server (that is, the real live version of your site), you should be able to effectively hide just about any JRun exception thrown to your users. This is obviously not a good excuse for poor debugging, but it can keep you from looking bad. Make sure you are logging or e-mailing the relevant people when these errors occur from within your error page.
The other subtags used allow us to specifically define error pages for specific types of errors. This can be a valuable technique for giving the users intelligent error messages that might help them to solve problems on their own:
<error-page> <exception>java.sql.Exception</exception> <location>/19/sqlException.jsp</location> </error-page>
This works almost exactly like the <error-code> approach, except that we are referencing the exception type (within the <exception> tags) instead of the HTTP error code. The error page's location is still placed between the <location> tags. Here, any SQL problems will be thrown to a specific page.
Error pages can be invaluable debugging tools. On your error pages, you can output information that is specific to the type of exception that occurred, including request or other parameters, path information, and any other type of data that can help you pinpoint the problem.
It might be helpful to create a few debugging templates and XML definitions to use in new applications when you begin building them. This can make the process smoother, and setting the 500 errors to a page that gives more information than the Java error message and stack trace can greatly improve the speed and quality of your development.