Hi,
It was always intended, and finally fixed in 6.0.19 (see the changelog). The
impetus was
this bug report:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42747
Thank you very much for the reference. To be helpful to other people who
stumble upon this thread when searching for information on this problem,
here I found an early comment made by Mark about this issue:
Sep 4, 2008: http://markmail.org/message/jhl4hvfdhrrgwjv6
Is there a different handling for packaged webapps (wars) vs. an
exploded directory?
There is a slight one. For WARs with a context.xml, it will get copied
to $CATALINA_HOME/conf/[enginename]/[hostname]/ if a <contextpath>.xml
does not exist. context.xml files in an exploded directory do not get
copied. This is an inconsistency that is on my list to fix as part of
fixing https://issues.apache.org/bugzilla/show_bug.cgi?id=42747
Another related thread is this one:
http://markmail.org/thread/ivrwdxm35cs3p3zs
Jul 20, 2009
What I want (as option): "I know that developer/packager did it right
and I never want to have local configuration. Always use the
*context.xml* within the currently deployed application, updated every
time I redeploy the app."
In this thread, Rainer Frey asks for the same thing, although the
difference is that back then it was about .war deployments and not about
exploded deployments.
The copying change makes it possible to edit
conf/Catalina/[host]/[appName].xml, regardless
of whether the origin was a .war or a directory.
Charles, I understand the benefits of this for a production environment,
especially when there is a dedicated deployment team. But why not go for
the following simpler procedure:
1. If there is a context descriptor in
$CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml use this.
2. Otherwise, use the context descriptor
$CATALINA_BASE/webapps/[webappname]/META-INF/context.xml
If that would be all, wouldn't everybody be happy? System administrators
can still override whatever is provided by the web application, but if
nobody puts something in
$CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml then the
version of the web application is used and the developer can simply
update things like datasources without having to change stuff inside a
local Tomcat installation.
It seems to me that for development the latter situation is much more
desirable. In our case (and I figure in a lot of other cases), the
source code for a web application is under version control. This
includes the META-INF directory and thus context.xml. If I check in a
change to context.xml, for instance if I created an additional
datasource for my code, then previously all developers would get this
change if they update their workspace.
With the recent changes however, I'll have to mail each and every
developer on our project to inform them they have to clear their
$CATALINA_BASE/conf/[enginename]/[hostname]/ directory, or otherwise
they will never get the change I just checked in. We have people working
at several different locations and some of those include less
technically inclined people who mainly work on texts. This kind of a
procedure is quite painful for every team member, but is especially
painful or perhaps even impossible for those less technically inclined
members.
How do others cope with this? I guess the problem would be solved if all
existing Tomcat server connectors for every IDE (we use MyEclipse),
takes this necessary cleaning of
$CATALINA_BASE/conf/[enginename]/[hostname]/ into account. On the other
hand, if this cleaning is a requirement for development, then it's
basically just a workaround for the fact that at least in development
mode, Tomcat might be better off not doing this
copying-once-and-holding-on-to-the-copy thing?
I might be missing something, so I would be grateful if someone can
enlighten me. At the moment this required copying seems plain wrong to
me on every possible level, but I fully understand that I might not be
seeing the bigger picture yet. As I said, I understand the benefits of
doing this, but I don't understand what's bad on (optionally) not doing
this copying.
But what counts as an "undeploy" for a static deployment?
Using the manager to do a real undeploy; deletion of the expanded directory is
only part of
it.
Hmmmm, but if you absolutely need the manager to do a proper deploy and
undeploy, doesn't that somehow imply that static deployment (just
copying and removing from the webapps directory) has become more or less
deprecated? I think most IDEs take advantage of the static deployment
method, although some of them (like Eclipse/WTP) do indeed have
knowledge of the conf/Catalina convention. Maybe it's thus only a
MyEclipse problem.
Besides the <Context> element, there are also files under Tomcat's work
directory
that must be removed.
Well, in practice this doesn't seem to be necessary that often. We have
several web applications with tons and tons of JSP files and have been
developing for Tomcat for years, but only occasionally it was needed to
clear this during development. Of course, for a production deployment we
do always clear this directory (just to be sure ;)).
Thanks again for all help so far.
Arjan
--
It's a cult. If you've coded for any length of time, you've run across someone
from this warped brotherhood. Their creed: if you can write complicated code,
you must be good.
