Thanks for the replies and suggestions. I don't think Tomcat falls back to the ROOT context if another context fails to start (unless I'm missing something).
Just to try it out, I did create a subfolder called "context1" in ROOT, with an index page in the folder. I made the context1 to fail. The log indicates that context1 failed to startup with the following error. SEVERE: Context [/context1] startup failed due to previous errors When I try an URL that starts with /context1, I still get Tomcat's default error page with a status code of 404, not the custom error pages I've in ROOT or the context1. If course, it will never be able to load the custom error pages from context1, it does not fall back to ROOT either. All other URLs (that do not start with /context1) display the custom error pages from the ROOT context. The main reason why we need custom error pages is for security - do NOT display any information about the product that may help a hacker to run sophisticated attacks. I guess, it may not be a bad idea for a product (container) to provide an option to override error pages. Sai Pullabhotla On Tue, May 24, 2011 at 1:15 PM, André Warnier <a...@ice-sa.com> wrote: > Caldarale, Charles R wrote: >>> >>> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com] Subject: Re: >>> Overriding error page displayed when a context fails to initialize >> >>> What I'm looking for is a way to override the error pages of Tomcat at >>> the global level (not application/context specific) >> >> There's no such mechanism mostly because the servlet spec doesn't provide >> for one. The ROOT webapp becomes the catch-all, and you can put filters and >> generic error pages there. >> > > Would the following work, e.g. ? > > Suppose there are 3 webapps : app1, app2, app3, > respectively deployed at > (tomcat_dir)/webapps/app1 > (tomcat_dir)/webapps/app2 > (tomcat_dir)/webapps/app3 > > plus the default ROOT context deployed at > (tomcat_dir)/webapps/ROOT > > and suppose you created 3 additional directories under webapps/ROOT, > respectively > > (tomcat_dir)/webapps/ROOT/app1 > (tomcat_dir)/webapps/ROOT/app2 > (tomcat_dir)/webapps/ROOT/app3 > > The standard Tomcat setup defines, in (tomcat_dir)/conf/web.xml, a "welcome > file list" as follows : > <welcome-file-list> > <welcome-file>index.html</welcome-file> > <welcome-file>index.htm</welcome-file> > <welcome-file>index.jsp</welcome-file> > </welcome-file-list> > > So, in each of the above new directories, you deploy a "index.jsp" page, > like > (tomcat_dir)/webapps/ROOT/app1/index.jsp > (tomcat_dir)/webapps/ROOT/app2/index.jsp > (tomcat_dir)/webapps/ROOT/app3/index.jsp > , each of these pages displaying a nice message like : > "Sorry, this xyz application failed to deploy and is not available". > > Then what would happen is : > - if all applications deploy properly, a request for the URL "/app1/x" would > be mapped to the application "app1" > - if app1 did not deploy properly, a request for the URL "/app1" would end > up being mapped to the default ROOT application and its sub-directory > "/ROOT/app1", thus returning the welcome page > (tomcat_dir)/webapps/ROOT/app1/index.jsp, and the message. > > No ? > > (The above was for the basic principle, but I suppose one could optimise > this, to avoid having to create these sub-directories and duplicating those > error pages, by mapping these things more cleverly in ROOT's web.xml.) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
