Hello Serge, Thank you for your reply. This option seems to be similar to the first thing i tried, editing conf/web.xml. As is suggested in http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcat
But contrary to what's stated in the stackoverlow message, this does not work if the error occours in the context of another web application. The following issue description is similar to mine; http://anthonyjdev.blogspot.nl/2012/09/custom-error-page-for-all-apps-in-tomcat.html In this case, even if the location is defined in conf/web.xml (global), the error pages are being searched for in the context of the web application that issued the error. In strict J2EE sense, i do understand that reasoning. That's not what i want though ;) If i am wrong about the understanding of all of this, please correct me. But i just tried that stackoverlow approach again and still it seems to be tied to the webapp that issues the error. Thank you, Regards, Maarten . 2013/12/31 Serge Fonville <serge.fonvi...@gmail.com> > 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 > > >
