You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by M4N - Arjan Tijms <ar...@m4n.nl> on 2009/08/06 18:44:01 UTC
Tomcat copies context.xml to conf/Catalina/localhost/app.xml but
never updates it?
Hi,
I'm running Tomcat 6.0.20 using JDK 6 update 14 on a 64 bits Debian
Lenny. I've unpacked a stock Tomcat 6.0.20 and deployed a web module to
the webapps directory. After I started and stopped the web module, I
noticed that the META-INF/context.xml had been copied to
conf/Catalina/localhost/[name of web module].xml.
I made a change to META-INF/context.xml and started Tomcat again, but
the copy in conf/Catalina/localhost/ appeared to be not updated. I
stopped Tomcat, removed the web module from webapps and started Tomcat
again. The copy in conf/Catalina/localhost still wasn't updated/deleted
and now Tomcat started complaining it couldn't find my webapp anymore.
I've been a long time Tomcat user and this has never ever been a problem
for me. I never noticed conf/Catalina/localhost contained a copy of my
context.xml files, but I could always modify context.xml and never
needed to explicitly delete the contents of conf/Catalina/localhost.
This is a rather scary situation. I'm not 100% sure why Tomcat does this
copying in the first place and I'm not at all sure what's going on with
the stale copies.
Anyone has any idea?
--
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.
---------------------------------------------------------------------
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 never updates it?
Posted by Mark Thomas <ma...@apache.org>.
Michael Ludwig wrote:
> Mark Thomas schrieb:
>> Michael Ludwig wrote:
>
>>> "Static deployment" does not seem to handle META-INF/context.xml -
>>> and that looks broken.
>>
>> No, static deployment is not deprecated.
>>
>> Static deployment *does* handle context.xml. It is working as
>> designed. If you delete the WAR/DIR *and wait for Tomcat to spot this*
>> then any CATALINA_BASE/<engine>/<host>/context.xml will be deleted.
>
> Not rather $CATALINA_BASE/conf/[engine]/[host]/[appname].xml ?
Correct. I was being lazy.
> And does it also apply when the [appname].xml wasn't copied there by
> Tomcat but placed there by the admin? I suspected that Tomcat doesn't
> distinguish between the two cases.
Also correct.
>> If you overwrite the WAR/DIR then the
>> CATALINA_BASE/<engine>/<host>/context.xml will be left alone.
>
> This should go into the doc (possibly in corrected form), unless it is
> there in some form and we haven't seen it.
Fourth bullet of this page:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
>>>> Currently the documentation says:
>>>>
>>>>> 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.
>>>> See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
>
> This seems to imply that you have to shut down Tomcat before static
> deployment.
That all depends what risks you are prepared to take. There is a chance
that Tomcat will spot the updated WAR and start to deploy it before the
copy has finished. If this happens then the deployment will be
corrupted. Larger WARs and copying over a slow network connection make
this more likely. A local move is far less likely to have an issue but
there is always a chance.
>>> It seems misleading indeed. Maybe the description of the "deployment
>>> sequence" should amend this sentence:
>>>
>>> | 1. Any Context Descriptors will be deployed first.
>>
>> This means any files found in
>> CATALINA_BASE/<engine>/<host>/context.xml
>
> Just to be 100% sure, does that mean: Any WARs or web application
> directories referenced from Context Descriptors found in
> $CATALINA_BASE/conf/[engine]/[host]/ ?
Correct.
The deployer how-to probably needs:
a) some tweaks
b) a reference to the context config page
Mark
---------------------------------------------------------------------
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 never updates it?
Posted by Michael Ludwig <ml...@as-guides.com>.
Mark Thomas schrieb:
> Michael Ludwig wrote:
>> "Static deployment" does not seem to handle META-INF/context.xml -
>> and that looks broken.
>
> No, static deployment is not deprecated.
>
> Static deployment *does* handle context.xml. It is working as
> designed. If you delete the WAR/DIR *and wait for Tomcat to spot this*
> then any CATALINA_BASE/<engine>/<host>/context.xml will be deleted.
Not rather $CATALINA_BASE/conf/[engine]/[host]/[appname].xml ?
And does it also apply when the [appname].xml wasn't copied there by
Tomcat but placed there by the admin? I suspected that Tomcat doesn't
distinguish between the two cases.
> If you overwrite the WAR/DIR then the
> CATALINA_BASE/<engine>/<host>/context.xml will be left alone.
This should go into the doc (possibly in corrected form), unless it is
there in some form and we haven't seen it.
>>> Currently the documentation says:
>>>
>>>> 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.
>>> See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
This seems to imply that you have to shut down Tomcat before static
deployment.
>> It seems misleading indeed. Maybe the description of the "deployment
>> sequence" should amend this sentence:
>>
>> | 1. Any Context Descriptors will be deployed first.
>
> This means any files found in
> CATALINA_BASE/<engine>/<host>/context.xml
Just to be 100% sure, does that mean: Any WARs or web application
directories referenced from Context Descriptors found in
$CATALINA_BASE/conf/[engine]/[host]/ ?
Like:
C:\MILU\Server\Tomcat60\conf\Catalina\localhost\import.xml
C:\MILU\Server\Tomcat60\conf\Catalina\localhost\xpgj.xml
--
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 never updates it?
Posted by Mark Thomas <ma...@apache.org>.
Michael Ludwig wrote:
> M4N - Arjan Tijms schrieb:
>
>>>> I always just copy my web application statically to Tomcat's webapps
>>>> directory ("$CATALINA_BASE/webapps") for the production server
>>> Insufficient, as Chuck has pointed out: use the manager app.
>>
>> Does that, basically, mean that the static deployment method is
>> deprecated?
>
> I'm getting this feeling, too. "Static deployment" does not seem to
> handle META-INF/context.xml - and that looks broken.
No, static deployment is not deprecated.
Static deployment *does* handle context.xml. It is working as designed.
If you delete the WAR/DIR *and wait for Tomcat to spot this* then any
CATALINA_BASE/<engine>/<host>/context.xml will be deleted.
If you overwrite the WAR/DIR then the
CATALINA_BASE/<engine>/<host>/context.xml will be left alone.
>> Currently the documentation says:
>>
>>> 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.
>> See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
>>
>> Reading this gives me the impression that I can use it. If I should
>> not use the static deployment mechanism, shouldn't this entry be
>> removed from the documentation?
>
> It seems misleading indeed. Maybe the description of the "deployment
> sequence" should amend this sentence:
>
> | 1. Any Context Descriptors will be deployed first.
This means any files found in CATALINA_BASE/<engine>/<host>/context.xml
Any suggestions to clarify the docs are welcome.
Mark
---------------------------------------------------------------------
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 never updates it?
Posted by Michael Ludwig <ml...@as-guides.com>.
M4N - Arjan Tijms schrieb:
>>> I always just copy my web application statically to Tomcat's webapps
>>> directory ("$CATALINA_BASE/webapps") for the production server
>> Insufficient, as Chuck has pointed out: use the manager app.
>
> Does that, basically, mean that the static deployment method is
> deprecated?
I'm getting this feeling, too. "Static deployment" does not seem to
handle META-INF/context.xml - and that looks broken.
> Currently the documentation says:
>
>> 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.
> See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
>
> Reading this gives me the impression that I can use it. If I should
> not use the static deployment mechanism, shouldn't this entry be
> removed from the documentation?
It seems misleading indeed. Maybe the description of the "deployment
sequence" should amend this sentence:
| 1. Any Context Descriptors will be deployed first.
to include a warning like:
Achtung! This will only happen if there is no Context Descriptor
present at the target location.
--
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 never updates it?
Posted by M4N - Arjan Tijms <ar...@m4n.nl>.
Hi,
Michael wrote:
>> I always just copy my web application statically to Tomcat's webapps
>> directory ("$CATALINA_BASE/webapps") for the production server
> Insufficient, as Chuck has pointed out: use the manager app.
Does that, basically, mean that the static deployment method is
deprecated? If that's true, why doesn't the Tomcat documentation mention
this?
Currently the documentation says:
> 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.
See: http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
Reading this gives me the impression that I can use it. If I should not
use the static deployment mechanism, shouldn't this entry be removed
from the documentation?
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.
---------------------------------------------------------------------
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 never updates it?
Posted by Michael Ludwig <ml...@as-guides.com>.
arjan.tijms schrieb:
> I always just copy my web application statically to Tomcat's webapps
> directory ("$CATALINA_BASE/webapps") for the production server
Insufficient, as Chuck has pointed out: use the manager app.
> and use MyEclipse for deployment during development.
If you use an Eclipse-managed Tomcat, you may then have to right-click
on the Server entry in the Servers view and choose "Clean". You might
want to check what's on the filesystem in the relevant directory before
and after cleaning (using something like dir /s /b) so you understand
what's going on.
--
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 never updates it?
Posted by Mark Thomas <ma...@apache.org>.
arjan.tijms wrote:
> On Thu, 06 Aug 2009 23:52:24 +0200, arjan.tijms <ar...@m4n.nl> wrote:
>>> Search the archives. This been covered repeatedly.
>>> Mark
>
> I did found this posting:
> http://mail-archives.apache.org/mod_mbox/tomcat-users/200906.mbox/%3c4A3F56C9.8050001@apache.org%3e
>
> You explain here the copying of the context.xml that's within a .war
> archive and a few posts later the reasons for doing so. Although maybe not
> explicitly documented, it seems Tomcat has been doing this at least for a
> while for .war archives.
>
> However, in my case I'm statically deploying an *exploded* web application.
> I just tested whether earlier Tomcat versions copied context.xml (I used
> Tomcat 6.0.14, 6.0.16 and 6.0.18) and none of these did the copying for
> static exploded deployments. Can you confirm that copying for exploded
> deployments is a new and intended behavior for Tomcat 6.0.20?
Did you look at the changelog?
> But what counts as an "undeploy" for a static deployment? If I just delete
> my statically deployed application from the webapps directory and restart
> Tomcat, then the files in conf/Catalina are still there.
Using the manager app will guarantee a proper undeployment.
Just deleting the directory whilst Tomcat is running should be
sufficient providing you have autoDeploy enabled and Tomcat has a chance
to spot the directory has been deleted before you copy the new version
across.
Mark
---------------------------------------------------------------------
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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by "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?
Posted by 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.
RE: Tomcat copies context.xml to conf/Catalina/localhost/app.xml
but neverupdates it?
Posted by "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 never updates it?
Posted by "arjan.tijms" <ar...@m4n.nl>.
On Thu, 06 Aug 2009 23:52:24 +0200, arjan.tijms <ar...@m4n.nl> wrote:
>>Search the archives. This been covered repeatedly.
>>Mark
I did found this posting:
http://mail-archives.apache.org/mod_mbox/tomcat-users/200906.mbox/%3c4A3F56C9.8050001@apache.org%3e
You explain here the copying of the context.xml that's within a .war
archive and a few posts later the reasons for doing so. Although maybe not
explicitly documented, it seems Tomcat has been doing this at least for a
while for .war archives.
However, in my case I'm statically deploying an *exploded* web application.
I just tested whether earlier Tomcat versions copied context.xml (I used
Tomcat 6.0.14, 6.0.16 and 6.0.18) and none of these did the copying for
static exploded deployments. Can you confirm that copying for exploded
deployments is a new and intended behavior for Tomcat 6.0.20?
If this is indeed intended behavior, then what is the rationale for it?
Unlike for .war deployments, I can just edit the embedded context.xml in an
exploded deployment directly so the "unpack, edit, pack" problems aren't an
issue here. Also, for development I'm running into issues too with the new
behavior. If I edit the context.xml file in Eclipse and save it, then
Tomcat 6.0.18 would pick up the changes. Since my IDE has no knowledge
about the file in conf/Catalina the result is that changes don't seem to be
picked up. Manually deleting the file in conf/Catalina on the command line
outside my IDE is of course not difficult but tedious nevertheless.
Also, in this post
http://mail-archives.apache.org/mod_mbox/tomcat-users/200906.mbox/%3c4A3F70CB.8050302@apache.org%3e
you say:
>If you want to remove the old configuration, undeploy the app first which
will remove the old configuration file.
But what counts as an "undeploy" for a static deployment? If I just delete
my statically deployed application from the webapps directory and restart
Tomcat, then the files in conf/Catalina are still there. Instead of
removing the configuration files, Tomcat gives the error that it can't find
the matching webapp anymore. Does this undeploy that should remove the
configuration file only works when undeploying via the manager app?
Arjan
---------------------------------------------------------------------
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 never updates it?
Posted by Mark Thomas <ma...@apache.org>.
arjan.tijms wrote:
>> Search the archives. This been covered repeatedly.
>> Mark
>
> Mark, I did try to search extensively, even after posting. A while after my
> post I continued searching but the only post that appeared at the top of
> the search results happened to be my very own post.
>
> I searched using keyword "conf/Catalina", "tomcat 6.0.20 conf/Catalina",
> "context.xml copied"
Then I think you need to use a better search engine. I'd recommend
MarkMail. Trying your third search above gives this:
http://tomcat.markmail.org/search/context%2Exml+copied+list:org%2Eapache%2Etomcat%2Eusers+order:relevance
> The Tomcat deployment documentation doesn't mention this copying and not
> updating of context.xml at all:
Try looking at the doc for Context elements.
Mark
---------------------------------------------------------------------
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 never updates it?
Posted by "arjan.tijms" <ar...@m4n.nl>.
>Search the archives. This been covered repeatedly.
>Mark
Mark, I did try to search extensively, even after posting. A while after my
post I continued searching but the only post that appeared at the top of
the search results happened to be my very own post.
I searched using keyword "conf/Catalina", "tomcat 6.0.20 conf/Catalina",
"context.xml copied" "context.xml not changed" "tomcat doesn't pick up
changes context.xml" "changed context.xml ignored", etc. As I mentioned,
I'm a long time Tomcat user. I always just copy my web application
statically to Tomcat's webapps directory ("$CATALINA_BASE/webapps") for the
production server and use MyEclipse for deployment during development.
The Tomcat deployment documentation doesn't mention this copying and not
updating of context.xml at all:
http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
It says this:
>The locations for Context Descriptors are;
>
>$CATALINA_BASE/conf/[enginename]/[hostname]/context.xml
>$CATALINA_BASE/webapps/[webappname]/META-INF/context.xml
>Files in (1) are named [webappname].xml but files in (2) are named
context.xml. If a Context Descriptor is not provided for a Context, Tomcat
configures the Context using default values.
And this:
>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.
>
>The web applications present in the location specified by the Host's
(default Host is "localhost") appBase attribute (default appBase is
"$CATALINA_BASE/webapps") will be deployed on Tomcat startup only if the
Host's deployOnStartup attribute is "true".
>
>The following deployment sequence will occur on Tomcat startup in that
case:
>
>Any Context Descriptors will be deployed first.
>Exploded web applications not referenced by any Context Descriptor will
then be deployed. If they have an associated .WAR file in the appBase and
it is newer than the exploded web application, the >exploded directory will
be removed and the webapp will be redeployed from the .WAR
>.WAR files will be deployed
>Note again that for each deployed web application, a Context Descriptor
will be created unless one exists already.
The first line of the second quote "then you'll need to deploy your web
applications statically to Tomcat" is my use case. I'm interested in doing
the static deploy. The last line says that a Context Descriptor will be
created, *unless* one exists already. The first quote makes it clear that
$CATALINA_BASE/webapps/[webappname]/META-INF/context.xml qualifies as a
Context Descriptor.
My web module/application contains a context.xml, yet Tomcat creates one in
conf/Catalina by copying the one from my (exploded) static deployment. I'm
frantically reading through every piece of Tomcat documentation that I can
get my hands on, but I just can't find a reference to this copying.
Meanwhile I'll try scanning every post in the Tomcat mailing list archive
manually, as my keyword searches seem to bring me nothing.
It would be very much appreciated if you could give me some keywords to
search on. An actual link would be even better of course, but I'm
absolutely willing to do the searching myself. To be sure, I want to make
it clear that I've been able to deploy statically to almost each and every
version of Tomcat since the late 4.x revisions. A version as recent as
Tomcat 6.0.18 didn't seem to have this problem.
Thanks in advance for all help.
---------------------------------------------------------------------
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 never updates it?
Posted by M4N - Arjan Tijms <ar...@m4n.nl>.
p.s.
M4N - Arjan Tijms wrote:
> I'm running Tomcat 6.0.20 using JDK 6 update 14 on a 64 bits Debian
> Lenny. I've unpacked a stock Tomcat 6.0.20 and deployed a web module
> to the webapps directory. After I started and stopped the web module,
> I noticed that the META-INF/context.xml had been copied to
> conf/Catalina/localhost/[name of web module].xml.
When I try to make the [tomcat install dir]/conf read only, I get the
following exception when starting up:
INFO: Starting Coyote HTTP/1.1 on http-8080
Aug 6, 2009 6:52:07 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Aug 6, 2009 6:52:07 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/19 config=null
Aug 6, 2009 6:52:07 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 137 ms
Aug 6, 2009 6:53:17 PM org.apache.catalina.startup.HostConfig
deployDirectory
SEVERE: Error deploying web application directory my_test
java.io.FileNotFoundException:
/opt/apache-tomcat-6.0.20/conf/Catalina/localhost/my_test.xml (No such
file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:957)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:909)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:495)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1274)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:296)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Thread.java:619)
It thus appears that Tomcat really wants to make this copy first and
then process only this copy. I however very much want this not to
happen. Is there any option that allows me to change this? What I need
is the Tomcat 6.0.18 and earlier behavior where META-INF/context.xml is
used from the webapps/someapp directory as-is, without any copying of
any kind.
Thanks in advance for all help
--
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.
---------------------------------------------------------------------
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 never updates it?
Posted by Michael Ludwig <ml...@as-guides.com>.
Mark Thomas schrieb:
> M4N - Arjan Tijms wrote:
>> Anyone has any idea?
>
> Search the archives. This been covered repeatedly.
Hint: Tomcat has a manager app.
--
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 never updates it?
Posted by Mark Thomas <ma...@apache.org>.
M4N - Arjan Tijms wrote:
> Hi,
>
> I'm running Tomcat 6.0.20 using JDK 6 update 14 on a 64 bits Debian
> Lenny. I've unpacked a stock Tomcat 6.0.20 and deployed a web module to
> the webapps directory. After I started and stopped the web module, I
> noticed that the META-INF/context.xml had been copied to
> conf/Catalina/localhost/[name of web module].xml.
>
> I made a change to META-INF/context.xml and started Tomcat again, but
> the copy in conf/Catalina/localhost/ appeared to be not updated. I
> stopped Tomcat, removed the web module from webapps and started Tomcat
> again. The copy in conf/Catalina/localhost still wasn't updated/deleted
> and now Tomcat started complaining it couldn't find my webapp anymore.
>
> I've been a long time Tomcat user and this has never ever been a problem
> for me. I never noticed conf/Catalina/localhost contained a copy of my
> context.xml files, but I could always modify context.xml and never
> needed to explicitly delete the contents of conf/Catalina/localhost.
> This is a rather scary situation. I'm not 100% sure why Tomcat does this
> copying in the first place and I'm not at all sure what's going on with
> the stale copies.
>
> Anyone has any idea?
Search the archives. This been covered repeatedly.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org