> Maybe you should be more precise as to what exactly you want to be able to
update mechanically.
Fair question. We have different environments - test, uat and prod. We want
the environments to be the same. We install multiple tomcat instances, so we
don't typically customize the tomcat install much - just add the jdbc jars
to lib folder. Then each environment has a tomcat instance containing the
war, and a context file. The context file we change a little - typically we
replace the start with this (currently using tomcat 6.0.32)
<Context disableURLRewriting="true" useHttpOnly="true"
privileged="false" allowLinking="false" crossContext="false">
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat
restarts -->
<Manager pathname="" randomClass="java.security.SecureRandom" />
Then we would add entries for resources, such as smtp and jdbc and some
entries to configure the app, e.g. so extra logging on test server, and
turning off access to test urls on production.
So our intention was to automate this all, except the initial installation
of tomcat. So when we have a new war ready to deploy, our automated build
process makes the war and makes an installer. We could then take that
installer, invoke it on the target environment. If first install, then it
would setup the service etc. If just an update, then I figured it would be
safer to remove service. That way if we make any tweaks to the service
configuration, they would be propagated to all environments. (currently we
update the windows service to add a variable to tell the app which
environment it is running under)
Apologies if nobody else is doing this - I truly assumed that this would be
a common need. I was aware of the manager app, and knew that you could call
ant tasks to deploy new apps to it. However I didn't think that the tasks
that it has would cover the whole range of installing a service etc
I also agree with your comment about "reinstalling the whole service seems
overkill to just deploy an updated war file". However without the ability to
deploy all the settings automatically via a script, I can't see how we can
guarantee that all environments are the same. Working on multiple projects,
it is just hard to keep all envs in sync all the time manually IMHO
Thanks for your suggestion
Chris
