Hello Maarten, When I was in the same boat, I found http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful.
I found these by googling https://www.google.nl/?gws_rd=cr&ei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+page&safe=off HTH Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl 2013/12/31 Maarten van Hulsentop <maar...@vanhulsentop.nl> > Hello, > > We are using Tomcat to host a number of web applications as a uniform > solution. We trying to implement something that seems to be an odd > requirement, even though it is really a use case for us. > > We would like to define a single [default] error page for all web > applications residing on this Tomcat instance. After some experimentation > and googling around, it seems that there is no clear-cut solution for this. > I see a few options; > > - Let the global conf/web.xml define error pages for all web applications > at once. However these are always relative to the web application context, > and require every web application to pack the error pages again, which is a > duplicate of resources and defeats the DRY principle. > - An Error reporting valve can be implemented to handle error pages. Simply > extend ErrorReportValve delivered from Tomcat and implement the report() > method. But then how should this report method behave? > 1- It could build up a HTML page from java code directly (as is being done > in the Tomcat default implementation of the ErrorReportValve). The downside > of this would be that it is not possible to style the page afterwards. > 2- It could fetch the HTML page from a location specified in configuration > (system property or otherwise) and stream it to the client. But is it > possible to have dynamic behavior in that case (jsp behavior). I think we > would need a RequestDispatcher for that and that is supposed to be in > context i presume. > 3- It could fetch the ROOT context (which has to be crossContext=true then > i assume) and delegate the handling of errors to a page in the root > context. This one would have my preference, as it allows the configuration > of a single error page, while trying to stick (mimic) as much of the normal > J2EE behavior as possible. But it also seems to be the most tricky one. > Also, i am not sure on the crossContext setting. Documentation points out > that it should not be set on security conscious environments. My experience > is that security is always important, so does this make it a no-no or is > this a theoretical security risk? > > Please share your opinions about this, things i missed, or (even better!) > your solution :) > > Thank you in advance! > Regards, > > Maarten van Hulsentop >
