Hi. I didn't find any way to customize a global 503 error page. Sure, that can't be on webapps level because when it's stopped it can't be reached. So it should give a way to customize that default tomcat error page at least for 503 errors. I've searched the web and mailing lists on this issue and no one got it solved. Someone said it's hardcoded in org.apache.catalina.valves.ErrorReportValve.report(). If that is the case, that would be really bad.
Bugzilla is not the forum to ask questions. Please post your question to the Tomcat users mailing list.
I didn't find any question mark in my sentences, did you? On the mailing list they say, it's hardcoded. It's surely no bug - but where can I put feature requests then?
I assumed there was an implied question "How do I set a global 503 error page?". The reply to your post on the users list points you towards how to customise this to use your own page.
Yes, errorReportValveClass should do the trick. Why is it so complicated for just an easy task? Ok, where can I put feature requests? Then you can close this one.
To register this an enhancement request, I have re-opened this issue and set the severity to enhancement. I also set a few other attributes. Why is it like this? The current approach works and no one has felt the need to change it. Obviously, enhancement requests with patches that implement them are more likely to make it into the codebase.
This Tomcat 5 enhancement request has been moved to Tomcat 7 (the latest version) since Tomcat 5 development is limited and focussed on bugs and security issues whereas Tomcat 7 is still seeing new feature development.
A decade plus on from when this was opened I'm planning on implementing a solution for this. The overall plan is: - Pass errors that happen early in the processing chain to the app / the container to handle where we can - Extend the ErrorReportValve to allow static pages to be defined for error codes and/or Exceptions. Progress so far is (all in 9.0.x): - I have refactoring the processing chain so we can pass errors. - I have started to refactor the handling of individual errors to pass them when the occur. This last point is throwing up various edge cases. Currently I am working on JSPs, TRACE and OPTIONS handling. I'm expecting the refactoring of the individual error cases to take a little while to sort out.
After a decade, reading my posts is embarassing in terms of politeness. My apologies. A little late - but better than never. Thanks you for finally looking into this :)!
No worries. I've written far worse in my time. Fixing this is turning up all sorts of interesting edge cases. I'm actually quite enjoying tackling it. This is one I've kept coming back to from time to time but hadn't - until this time - found a way of tackling it that I was happy with. The clean up to the connector code that we've done since this was first raised back in the days of 5.x has certainly helped.
A quick update. I believe the refactoring to enable the application/container error handling to handle error reporting is complete. The errors that aren't processed this way are: - any error that is so severe it requires the immediate closure of the network connection - any error that occurs after the request/response has left the standard processing pipeline (i.e. once it is too late for the application error handling or the ErrorReportValve to do anything). This has only been completed for 9.0.x and - given the refactoring involved - is unlikely to be back-ported. Next up is extended in the ErrorReportValve to enable static pages to be used for given errors.
The ability to specify a static error page for given status codes and/or exception types has now been added to the ErrorReportValve. It will be included in 9.0.6 onwards.
Back-ported to 8.5.x for 8.5.78 onwards