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