Handling release management with Tomcat

[Johannes Fiala <to...@fwd.at>]

Hi there,

We have a multiple server and multiple release system using Tomcat 4.1.18.
Given the issues we have to address we want to ease updating from version 
to the other without facing big risks or interoperability issues. Servers 
acting as clients calling soap requests etc. should be able to stick with 
lower-level releases or test beta-releases easily.

I'd propose the following procedure for dealing with multiple releases 
easily:
{$TOMCAT_HOME}/webapps/myapp-1.0
{$TOMCAT_HOME}/webapps/myapp-1.1
{$TOMCAT_HOME}/webapps/myapp-1.2beta
{$TOMCAT_HOME}/webapps/myapp-1.3alpha

main application entry:
{$TOMCAT_HOME}/webapps/myapp

Above are the separate versions of the Tomcat Contexts of "myapp". 
To switch between the different versions of myapp, two options exist in my 
opinion:
*) using a symbolic file system link to point to the version of myapp 
which is the "lead" version
*) using JK to link to the proper myapp-x.x directory (only possible with 
Apache/Tomcat connected with JK).

Which version do you think is preferable? 
Do different options exist which make more sense?

The release management should allow to:
*) decide to still take the "lower level" release (e.g. 1.0) explicitly, 
so clients could take the link with myapp-1.0 to do so. 
*) decide to test a "higher level beta" release (e.g. 1.2beta)

However, the main entry focuses on the "current release". Hotfixes could 
be dealt with that system as well.

What do you think ? 
Johannes