RE: Tomcat copies context.xml to conf/Catalina/localhost/app.xml but neverupdates it?

["Caldarale, Charles R" <Ch...@unisys.com>]

> From: arjan.tijms [mailto:arjan.tijms@m4n.nl]
> Subject: Re: Tomcat copies context.xml to
> conf/Catalina/localhost/app.xml but neverupdates it?
> 
> Can you confirm that copying for exploded deployments is a new 
> and intended behavior for Tomcat 6.0.20?

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

> Unlike for .war deployments, I can just edit the embedded 
> context.xml in an exploded deployment directly

The copying change makes it possible to edit conf/Catalina/[host]/[appName].xml, regardless of whether the origin was a .war or a directory.

> 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.  Besides the <Context> element, there are also files under Tomcat's work directory that must be removed.

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

Re: Tomcat copies context.xml to, conf/Catalina/localhost/app.xml,but neverupdates it?

[Len Popp <le...@gmail.com>]

On Fri, Aug 7, 2009 at 10:33, M4N - Arjan Tijms <ar...@m4n.nl> wrote:

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


Unfortunately it's not that simple. Take for example the most common case, a
<Resource> definition for a JDBC database connection. The app writer has to
provide part of the definition (the resource name, e.g. "jdbc/myAppDB") and
the sysadmin has to provide another part (the address of the DB server).
When the application vendor is different from the installer/maintainer, the
context.xml has to be customized at install time.

With most software, you get a text file that has to be edited to customize
the configuration data before you run the app. The difference with Tomcat is
that the app is usually packed into a .war file and it's a PITA to edit
context.xml and re-pack the .war. The alternative is to deploy the app
(which will unpack context.xml into conf/Catalina and then crash) and then
edit the site-specific configuration info. Neither way is terribly
convenient.
-- 
Len

Re: Tomcat copies context.xml to, conf/Catalina/localhost/app.xml,but neverupdates it?

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arjan,

On 8/7/2009 10:33 AM, M4N - Arjan Tijms wrote:
> 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.

This is a mechanism to protect cowboy developers against overwriting
carefully-constructed deployment descriptors written by deployment
experts. If the deployment folks are just updating the WAR (or exploded
WAR... whatever), they don't expect the deployment to suddenly change.
On the other hand, if the webapp is /undeployed/ and then re-deployed,
then the deployment folks need to make sure that they are working with
an updated deployment descriptor, and will either accept the one from
those cowboy developers, or craft a new one using the WAR file and old
carefully-crafted deployment descriptor as a reference.

> It's just this
> "copy-from-local-and-use-as-global-but-only-for-the-first-time" that
> just raises questions with me.

It's more like copy-from-local-and-use-as-global-on-initial-deployement.
Re-deployment doesn't count as deployment.

Again, everyone keeps telling you that your woes will disappear if you
do an undeploy/deploy instead of a re-deploy. How often does your
context.xml file change, anyway? :)

> Maybe the one who writes the Tomcat documentation could make this a
> little clearer?

Patches are always welcome, including for documentation.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkp8gX4ACgkQ9CaO5/Lv0PDJdgCgvKqNM1ig0jqUDcKtrVlPZElu
mBsAmQHBWwWIJBIJyb7lz3D+I0CSR5pK
=P9qP
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Tomcat copies context.xml to, conf/Catalina/localhost/app.xml,but neverupdates it?

[Michael Ludwig <ml...@as-guides.com>]

M4N - Arjan Tijms schrieb:

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

Maybe you have a point here. Isn't the problem that once a context
descriptor from META-INF/context.xml is copied to its target destination
in $CATALINA_BASE/conf/[engine]/[host]/[app].xml Tomcat forgets that it
is just a copy from somewhere else and treats it exactly as any context
descriptor that was there before and - naturally - refuses to overwrite
it with anything else as it might well be the one and only master copy?

-- 
Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Tomcat copies context.xml to, conf/Catalina/localhost/app.xml,but neverupdates it?

[M4N - Arjan Tijms <ar...@m4n.nl>]

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.

RE: Tomcat copies context.xml to conf/Catalina/localhost/app.xml,but neverupdates it?

["Caldarale, Charles R" <Ch...@unisys.com>]

> From: M4N - Arjan Tijms [mailto:arjan.tijms@m4n.nl]
> Subject: RE: Tomcat copies context.xml to
> conf/Catalina/localhost/app.xml,but neverupdates it?
> 
> 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.

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

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.  If you would simply follow the documented procedures rather than inventing your own (or relying on a poorly implemented 3rd-party one), you would not be having a problem.

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

As stated before, that's not the only thing that needs cleaning; at a minimum, the work directory must be purged for reliable operation.  Whatever else needs cleaning up can vary across Tomcat versions.  Again, use the published and documented mechanisms, not your own.

 - 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: Tomcat copies context.xml to conf/Catalina/localhost/app.xml, but neverupdates it?

[M4N - Arjan Tijms <ar...@m4n.nl>]

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.