Hi,
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
That is exactly how it works today.
Well, in my humble opinion this is how it worked yesterday. Doesn't it
work like this today (for exploded archives):
1. If there is a context descriptor in
$CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml use this.
2. Otherwise, *copy* the context descriptor
$CATALINA_BASE/webapps/[webappname]/META-INF/context.xml to
$CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml
3. Go 1.
I fully understand the need for global overrides, but the procedure of
copying the very first encountered context.xml from a web application
and then continue to use that as the global override variant, I'm sorry
but I just don't see the logic in doing that. Are there any other
systems out there using a similar mechanism? I'm thinking broadly here,
trying to think of general Linux configuration systems, other web
servers, programming languages, etc. I'm not sure that I've ever
encountered a system where a local configuration can be overridden by a
global configuration, but in absence of a global override the local
version is copied and kept indefinitely.
It just seems really awkward. Basically what you're saying is that you
don't trust the web application to provide a correct context.xml,
-except- for the first time. Isn't that a little arbitrary? Either you
trust the web application or you don't. If you don't trust the web
application the maintainer of a Tomcat instance puts his own context.xml
in conf/Catalina, thereby overriding whatever the web application
defines. If you do trust the web application, you don't put anything in
conf/Catalina. These are basic mechanics that you find in tons of
systems where a global configuration overrides a local one or the other
way around (depending on what you see as global or local).
It's just this
"copy-from-local-and-use-as-global-but-only-for-the-first-time" that
just raises questions with me. Sure, I can work around it. I can also
use another servlet container or if I'm really desperate patch the
Tomcat source code to not do this copying anymore. It's a free world and
thankfully nothing is holding anyone to anything here. The reason for
prolonging this discussion however is to hopefully get some light behind
the rationale of doing this initial copying.
Not true; the only reason it becomes an issue in your case is because you're
not doing a proper
redeployment. You cannot simply copy a new .war file into the appBase
directory and expect
it to work.
I see, that's my bad then. But to my defense, it has worked for many
years this way, the manual suggests this is the way to do this and my
IDE (not the highest authority of course, but really used a lot and not
some obscure little known one) also does it this way and basically
nearly every place where I ever came across does it this way. Up until
recently I had very little reason to assume this was not the correct way.
Maybe the one who writes the Tomcat documentation could make this a
little clearer? If I read the documentation here:
http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html it really
says that just copying the exploded or compressed web application to the
appBase location should work. It doesn't mention that officially this
only works the first time and not the second time.
i.e. shouldn't the following:
If you are not interested in using the Tomcat Manager, or TCD, then
you'll need to deploy your web applications statically to Tomcat,
followed by a Tomcat startup. The location you deploy web applications
to for this type of deployment is called the |appBase| which is
specified per Host. You either copy a so-called /exploded web
application/, i.e non-compressed, to this location, or a compressed
web application resource .WAR file.
Become
If you are not interested in using the Tomcat Manager, or TCD, then
you'll need to deploy your web applications statically to Tomcat,
followed by a Tomcat startup. The location you deploy web applications
to for this type of deployment is called the |appBase| which is
specified per Host. You either copy a so-called /exploded web
application/, i.e non-compressed, to this location, or a compressed
web application resource .WAR file. *Warning: This only works the
first time. For a redeployment you need to follow the following
procedure [...]*
Not trying to be smart or anything, just hoping to help out.
Kind regards,
Arjan Tijms
--
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.
