You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sai Pullabhotla <sa...@jmethods.com> on 2011/05/24 14:59:01 UTC
Overriding error page displayed when a context fails to initialize
I've a web application with two contexts "ROOT" and "mycontext". Both
contexts have custom error pages defined in the web.xml and everything
works as expected in most cases. The only problem is that if my
context, mycontext, fails to initialize (e.g. database is
unavailable), and if some one tries to access a page from context1,
Tomcat falls back to the default error pages. Is there a way to
override the default error pages in this case?
Thanks in advance for your help.
Sai Pullabhotla
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
Posted by Sai Pullabhotla <sa...@jmethods.com>.
Thanks every one for your useful tips and suggestions. I was able to
override the container's default error page using a custom error
valve. For any one else that may have a need to do this...
The key is to configure your Host element in the config to override
the error report valve. This took a while for me to find out, but it
is documented in the Tomcat docs (never paid attention, I guess). On
the Host element, you can define errorReportValveClass attribute as
documented in http://tomcat.apache.org/tomcat-6.0-doc/config/host.html.
As far as implementing the custom valve, the easiest is to extend the
org.apache.catalina.valves.ErrorReportValve and override the
report(...) method to send your own HTML.
Sai Pullabhotla
On Wed, May 25, 2011 at 5:48 PM, Sai Pullabhotla
<sa...@jmethods.com> wrote:
> I made the context fail by not having the database available.
> Basically, in the contextInitialized method, we need to load various
> application settings from the database and if the DB is not up, the
> context fails to load.
>
> The custom error pages are defined in the web.xml for ROOT and
> context1. All error codes and specific exceptions are forwarded to an
> ErrorHandlerServlet, which performs additional logging, create custom
> titles and descriptions based on the error code/exception and then in
> turn forwards to a JSP which displays the error.
>
> I will take a look at the ErrorReportValve and see if I could make use of it.
>
> Thanks.
>
> Sai Pullabhotla
>
>
>
> On Wed, May 25, 2011 at 9:04 AM, Pid <pi...@pidster.com> wrote:
>> On 25/05/2011 13:36, Sai Pullabhotla wrote:
>>> 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
>>
>> How did you make it fail?
>>
>>
>>> 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.
>>
>> How have you defined the custom error pages?
>>
>>
>>> 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.
>>
>>
>> @See ErrorReportValve
>>
>> http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/ErrorReportValve.html
>>
>> http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
>>
>>
>> p
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
Posted by Sai Pullabhotla <sa...@jmethods.com>.
I made the context fail by not having the database available.
Basically, in the contextInitialized method, we need to load various
application settings from the database and if the DB is not up, the
context fails to load.
The custom error pages are defined in the web.xml for ROOT and
context1. All error codes and specific exceptions are forwarded to an
ErrorHandlerServlet, which performs additional logging, create custom
titles and descriptions based on the error code/exception and then in
turn forwards to a JSP which displays the error.
I will take a look at the ErrorReportValve and see if I could make use of it.
Thanks.
Sai Pullabhotla
On Wed, May 25, 2011 at 9:04 AM, Pid <pi...@pidster.com> wrote:
> On 25/05/2011 13:36, Sai Pullabhotla wrote:
>> 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
>
> How did you make it fail?
>
>
>> 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.
>
> How have you defined the custom error pages?
>
>
>> 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.
>
>
> @See ErrorReportValve
>
> http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/ErrorReportValve.html
>
> http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
>
>
> p
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
Posted by Pid <pi...@pidster.com>.
On 25/05/2011 13:36, Sai Pullabhotla wrote:
> 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
How did you make it fail?
> 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.
How have you defined the custom error pages?
> 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.
@See ErrorReportValve
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/ErrorReportValve.html
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
p
Re: Overriding error page displayed when a context fails to initialize
Posted by Sai Pullabhotla <sa...@jmethods.com>.
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 <aw...@ice-sa.com> wrote:
> Caldarale, Charles R wrote:
>>>
>>> From: Sai Pullabhotla [mailto:sai.pullabhotla@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: Sai Pullabhotla [mailto:sai.pullabhotla@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Overriding error page displayed when a context fails to
initialize
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Sai Pullabhotla [mailto:sai.pullabhotla@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.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
Posted by Sai Pullabhotla <sa...@jmethods.com>.
Thanks for the reply, Chris.
We do several things during context initialization with the
ServletContextListener hook. The contextInitialized method may not
complete for various reasons, sometimes with checked exceptions and
sometimes with unchecked exceptions. We just let Tomcat/JVM handle the
unchecked exceptions. We do not have any custom filter that checks the
"health of the context" at the moment. What I'm looking for is a way
to override the error pages of Tomcat at the global level (not
application/context specific), but container specific. For example, if
I can define an error page/template in server.xml or something like
that. Just checking to see if there is way to override this in Tomcat.
In the mean time, I will see if I can have a "catchall" during context
initialization and see how various pieces (individual URLs) of the
application react when the context really failed to initialize.
Sai Pullabhotla
On Tue, May 24, 2011 at 8:10 AM, chris derham <ch...@derham.me.uk> wrote:
> On Tue, May 24, 2011 at 9:59 AM, Sai Pullabhotla <
> sai.pullabhotla@jmethods.com> wrote:
>
>> I've a web application with two contexts "ROOT" and "mycontext". Both
>> contexts have custom error pages defined in the web.xml and everything
>> works as expected in most cases. The only problem is that if my
>> context, mycontext, fails to initialize (e.g. database is
>> unavailable), and if some one tries to access a page from context1,
>> Tomcat falls back to the default error pages. Is there a way to
>> override the default error pages in this case?
>>
>> If the application throws an exception during context initialization, then
> the web app is not loaded. Hence your custom error pages won't be defined.
> The logical choice would be to stop the app from failing during context
> initialization - well at least stop it from throwing an exception. Then the
> app would still load into tomcat, and so the custom pages would still work.
> Can you perform the initialization using lazy instantiation?
>
> I guess the question is what do you want to happen when db fails during
> context initialization? You could have a flag and a filter that redirects to
> a "all broken" jsp if the app can't connect to the db?
>
> HTH
>
> Chris
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
Posted by chris derham <ch...@derham.me.uk>.
On Tue, May 24, 2011 at 9:59 AM, Sai Pullabhotla <
sai.pullabhotla@jmethods.com> wrote:
> I've a web application with two contexts "ROOT" and "mycontext". Both
> contexts have custom error pages defined in the web.xml and everything
> works as expected in most cases. The only problem is that if my
> context, mycontext, fails to initialize (e.g. database is
> unavailable), and if some one tries to access a page from context1,
> Tomcat falls back to the default error pages. Is there a way to
> override the default error pages in this case?
>
> If the application throws an exception during context initialization, then
the web app is not loaded. Hence your custom error pages won't be defined.
The logical choice would be to stop the app from failing during context
initialization - well at least stop it from throwing an exception. Then the
app would still load into tomcat, and so the custom pages would still work.
Can you perform the initialization using lazy instantiation?
I guess the question is what do you want to happen when db fails during
context initialization? You could have a flag and a filter that redirects to
a "all broken" jsp if the app can't connect to the db?
HTH
Chris