This is a somewhat different question about Tomcat deployment. It has been covered partially by earlier questions but I would like to here from those who have actually done Tomcat deployments.

In my organization I see two types of deployment.

1. WAR deployment to Tomcat *webapps* dir. Tomcat is stopped, the existing WAR file is renamed, the existing app directory under webapps (*appBase*) is removed, the new WAR is copied in and Tomcat is restarted.
The upside: deploying WARs seems to be understood by everyone.
There are two downsides that I can see.
A. if the WAR contains deployment specific information, such as DB connect info, the development environment requires some sort of version and build control to make sure the correct deployment-specific information goes into a WAR file. This could get complicated.
B. Many steps, not difficult but each step is a potential point of error.
2. *appBase* points to the application file system, deployment-specific information kept elsewhere. The applications deployable file system or a WAR file is copied to a location on the Tomcat box. The appBase attribute for the application in Tomcats *Servlet.xml* is modified to point to the newly deployed code. Tomcat is restarted after the copy.
All deployment specific config information is kept in a separate directory under [tomcat\_root] that is not affected by the deployment. If any changes are required the edits can be made any time and Tomcat restarted to pick up the changes. The upside: dead simple, usually only one step, at most two steps The downside: file editing on the deployment machine may be required. This is not allowed in many production environments or must be done by a sys admin not the deployment person. May cause delays, political problems and finger pointing if something
goes wrong.

As I said above, I would like to hear real world experience with either method. I definitely favor the second method. I wonder what the attraction of the first is since
it seems to be much more error prone.

Thanks,
-=b