tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Armbrust <>
Subject Re: Problem on Tomcat 6.0.20
Date Tue, 02 Feb 2010 22:57:22 GMT
On Tue, Feb 2, 2010 at 3:23 PM, Caldarale, Charles R
<> wrote:
>> From: Richard Sickler []
>> Subject: Re: Problem on Tomcat 6.0.20
>> I removed a file and a directory named WebApplication2, and that
>> cleared up that problem.  On to the next undocumented feature!
> It's fully documented:
> Context elements may be explicitly defined:
> ...
>    * ... If the web application is packaged as a WAR then /META-INF/context.xml will
be copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to match the application's
context path. Once this file exists, it will not be replaced if a new WAR with a newer /META-INF/context.xml
is placed in the host's appBase.

Documented, yes.  Astonishingly silly and surprising behaviour?  Also yes.

Good luck getting them to improve it.

Near as I can tell, this surprising and bizarre behaviour occurs
because Remy likes it that way.

In my opinion, Tomcat should remember if it copied the file out of a
war file... and if the war file is replaced, it should overwrite the
file with the new file from the new war file.

Is it trivial?  Not exactly, Tomcat would have to somehow keep track
of if the file was manually modified or not... but really, it just
needs to keep a hash of the file somewhere so it can check if the file
has been changed since it put it there.

I think Tomcat should also log a warning message when it doesn't copy
a context.xml from a war file... because the developer has made a
mistake at this point - someone manually changed one version, but
didn't change the one in the war file.

The current "design" leads to people having problems like you have -
because beginning developers aren't (and really) shouldn't have to be
aware of this nasty gotcha of Tomcat.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message