Hi,

   I have a webapp that needs to be down if we are doing some
maintenance. I use the manager to make the application unavailable but
in this case the 404 customized error-page is not displayed.

I modified the default web.xml (in conf/) to add the error-page 404,  
but it doesn't seems to be resolved when the context is stopped.

If I type an URL that doesn't exists, that doesn't map to any context, I
get the right error page. But if it match a context path of a webapp
that is stopped, I have the Tomcat default error page. Is there a way to
fix this?

Thanks

Tomcat 6.0.20

Hi,

Likely someone has a better idea...

You could create a general error page that redirect (transparently) to
a page of the webapp when available, if not, display another
If this is the default page for all webapps, it should be solved.
You will probably need to create a valve of some sort.
Don't ask me for details I honestly don't know.

Hopefully someone else can be more helpful, it's just a suggestion

HTH

Regards,

Serge Fonville

Is the error page inside a stopped webapp, or elsewhere - if so where?

How are you mapping the URL of the error page, post the fragment please?

p

We avoid all of this by replacing the webapp with a maintenance app. Theapp
indicates the period of downtime, who to call, etc for all urls. When weare
done, we deploy the application back. Also as prt of this all of our
applications use a common login/header facility which ckecks to see if a
maintenance event is near to 1. warn users to save and log out, 2.prevent new
logins, 3. disable the app until event is over (or replaced bymaintenance app).

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc.  http://www.pdinc.us  -
- Principal Consultant              10 West 24th Street #100    -
-  1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

My first inclination is that this a bug or enhancement request.

From a user point of view, if I have an app (which is not the root
webapp) and I stop it, then all requests should then go to the root
webapp. Of course doing this might introduce bad side effects during the
course of an application restart.

As a workaround, there is an option in Tomcat to use your own
ErrorReportValve. This might be an option. http://tomcat.apache.org/tomcat-6.0-doc/config/host.html  - see
errorReportValveClass

-Tim

Is that really true?  If the webapp is undeployed, I can understand that unmatched requests will be handled by ROOT, but a stopped webapp is still known to Tomcat, just not available.

- 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.

From a high level, whats the difference between a webapp thats stopped
and a webapp thats undeployed?

One could call stopped a special scenario. In the past - a 503 was
returned to the user. Now its a 404. IIRC ... it changed to 404 as part
of a bug report but maybe that is the wrong change to make. (Too lazy to
look up the bug report)

[Personally - I'd rather stick apache in front let apache trap the
condition during the outage window and not worry about the rest.]

-Tim

Le 20/08/09 15:41, Pid a écrit :

I tried twice : the error page is inside the root weapp AND the stopped
webapp.

[cough] [ahem]

(attempts to draw attention to the second question, above)

p

When a webapp is undeployed it is deleted from the webapps directory.
When it's stopped it's not deleted and can simply be re-started. In
this case it sounds like the OP is doing some maintenance outside of
the webapp (database updates, maybe) and just needs to stop the webapp
temporarily.

I don't know about that change, but in the past it wasn't possible to
specify a custom error-page for a stopped webapp. (I can't get to my
test server today to see if this is still the case.)

How would you trap the condition? Apache httpd's ErrorDocument
directive won't work because as long as Tomcat is running you get
Tomcat's error pages.

If you stop Tomcat completely then you can use Apache's ErrorDocument
to show a "site down" page, but not if you just stop one webapp in
Tomcat.

--
Len

Since there is manual intervention to stop the app. There can be manual
intervention to tell apache not to forward requests to tomcat, for example:
- change the apache config and graceful restart (but it does require a
restart)
- Use mod_rewrite to look for some marker (file existence or rewrite map
setting) and use that as a toggle to a 404 page.

-Tim

Le 20/08/09 17:48, Pid a écrit :

I added in ${CATALINA_HOME}/conf/web.xml
<error-page>
<error-code>404</error-code>
<location>/my404.html</location>
<error-code>503</error-code>
<location>/my503.html</location>
</error-page>

and copied the 2 html files in ${CATALINA_HOME}/webapps/ROOT

I do not really *know* this, but based on the XML structure of other
Tomcat config files, the above form looks fishy to me.
Should it not at least be something like

Le 20/08/09 21:25, André Warnier a écrit :

Yes, of course, you are right : just a stupid copy/paste in the mail :-[

But the result is the same

This config would try to reference a file of that URL in *each* webapp.
If Tomcat is holding onto URL namespaces when an given webapp is
stopped, then you'll get the default error page you're seeing, because
the app is stopped - so the file is unavailable.

Using a custom ErrorReportValve as previously suggested is the only way
to get generate the behaviour you're aiming for, because Valves operate
at a level below the webapp - thus a stopped webapp is no impediment.

p