tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <>
Subject Re: Deployement of war and context.xml files
Date Thu, 11 May 2006 07:56:05 GMT
2006/5/11, Thomas Whitmore <>:
> Hi Henri,
> Apparently  /conf/Catalina/localhost  is meant to represent the 'current deployed state'
of contexts/ webapps deployed.
> So it's reasonable from this understanding, that the Context specifier file is deleted
when you undeploy the app;  the context is being removed from the 'current state'.  Since
the complete deployer rewrite in TC 5.5,  Tomcat now takes significant ownership of both /conf/[engine]/[host]
 and /webapps.
> My guess is that with the  Customer-specific app customization, that you wish to have
the same .war deployed with different varying Context specifiers.  (Probably different context
paths for these, too?  I found huge problems with context paths since 5.5).  And that you
want each Context specifier to be a separate file, for modularity.
> The sensible way for Deployment to work, would be to supply a Context specifier file
and a WAR or DocBase.  These would be placed into a location owned by the User (you).  You
would then tell Tomcat to deploy (mount) the Context, or allow it to auto-deploy...
> Unfortunately 5.5 seems to be a balls-up, with Tomcat auto-creating 'current mounted
state' contexts for WARs and webapp folders it finds, auto-deleting webapps/ folders on undeploy
or after editing 'current state' context files, failing to match explicit Context specifiers
and thus producing spurious default deployments of the webapps, and with the 'Context Path'
attribute almost completely broken.
> As far as I am aware the locations to specify Contexts are, in order;  'server.xml' as
an XML element;  META-INF/context.xml inside the webapp;  or  /conf/[engine]/[host]  directory.
For deployment-specification customization obviously you need a Context file, independent
of the webapp;  the only place to put this is in  /conf/[engine]/[host];  this location is
most subject to the auto-magic working against you.
> Best answer:-
> -  use an Ant 'deploy' script from your Dev system
> -  call Manager.Deploy  and also specify a Context xml file
> -  may need to create a staging directory on the server under your control;
>         so Tomcat has somewhere it can see to pick up the files;
>         but safe from TC's  auto-scrubbing within /webapps
> -  lastly;  Context Path specifiers, or possibly other important bits, may just not work
> I would like to see very great clarification  in this area. (Hi guys). I think there
is a semantic misunderstanding in failing to distinguish MOUNTING from DEPLOYMENT of webapps.
Mounting should be Tomcat's responsibility, deploying - copying it to where TC can mount it
or replicate it around the cluster - should be the User's responsibility.
> This semantic error appears to have led to a (broad) range of TC behaviours in 5.5 which
are different from previous deployment concepts;  and just plain unlikable to developers.
> Now if  MOUNTING and mounted state were kept separate from  DEPLOYMENT,  /webapps and
deployment area would not be subject to being scrubbed &  trodden-upon like they currently
are.  Information flows & effects would be well-defined, as opposed to current flows which
are poorly-defined and effects which are undesirable.

Well a very welcomed approach.

The goal allow an UPDATE on an existing webapp :)

> Keeping  terminology clear, information well structured, and avoiding conflation of ideas,
are key to design of simple, robust & correct software.  Basically I'd say deployment
in 5.5 is an example of failure in these areas.
> Lastly,
>   stop tramping on my /webapps directory already!
> Hope you can sort out your deployment to work effectively in this version - I ended up
using a workaround  :-(   Anyway, let me know if this helps.
> Regards,
> Thomas

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

View raw message