I use virtual hosts, but don't think that is the cause, although I have not
traced this down (I will check that aswell). As I think of it, the webapp
could simply be empty one with a web.xml like:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";>
<web-app>
<error-page>
<error-code>404</error-code>
<location>/errors/404.html</location>
</error-page>
</web-app>
Now, when I request any file through Tomcat, it will fail (error 500: Stack
overflow). When a JSP is specified for <location>, it works fine. Tomcat
outputs a correct message from the CM about the requested error page, but
FileHandler outputs the originally requested path as requested file.
I will set up an independent Tomcat installation and try this again without
virtual hosts. If I have the time today, I will wrap up a webapp and post
the .war file.
----- Original Message -----
From: "Marc Saegesser" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 29, 2001 8:54 PM
Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
> Could you please supply a sample webapp that demonstrates this? Static
> error pages seem to work OK for me.
>
> > -----Original Message-----
> > From: Peer Heijnen [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, May 29, 2001 5:52 AM
> > To: tomcat-dev
> > Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2
> >
> >
> > I'm using Tomcat 3.2.2 (relase) and have configured static .html files
as
> > error pages. We used JSP pages before, and everything was fine...
However
> > since we're using static files, Tomcat will enter an infinite loop and
> > eventually crash with a stack overflow (with a good change of
> > leaving Tomcat
> > in a defunct state). We traced down this problem and have found a
> > way to fix
> > it, but I'm not sure if this is correct.
> >
> > All this is related to the ContextManager class:
> >
> > 1) Both handleStatus and handleError will call 'getHandlerForPath' when
an
> > error page was configured.
> > 2) getHandlerForPath returns a the Handler for the error page.
> > (since we're
> > using static files, this will be a FileHandler). So far, so good.
> > 3) Eventually handleStatus and handleError will do a
> > 'errorServlet.service( req, res )' to service the error. This is
> > were things
> > go wrong.
> >
> > The problem is, that 'req' passed to the 'errorServlet.service(
> > req, res )'
> > call is the original request, while getHandlerForPath creates a
> > new request
> > internally with the error's request URI. Since the handler
> > (FileHandler) is
> > called with the original request URI, it will try to service a
> > file matching
> > that request, not the static file we configured. This, in turn, will
cause
> > and error and, in our case, an infinite loop.
> >
> > This can lead to very strange situations. For example, if an .jsp page
> > generates an error and the error refers to an (existing) static file, it
> > will actually end up showing the .jsp source file contents!
> >
> > The quick and dirty fix we use here is to simply add 'req.setRequestURI(
> > ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both
> > handleError and handleStatus methods. I'm not really sure if we
> > are allowed
> > to modify the request in such a way, but error attributes are also set
in
> > this request and it seems to work fine for us. But this raises another
> > question: why construct a completely new request and response in
> > getHandlerForPath, and then throw it away?
> >
> > Cheers,
> > Peer Heijnen
>
