2006/5/11, Thomas Whitmore <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
