I inherited a test system where the Tomcat and JVM didn't match those on the production server – and it matters. Yet I can't change the versions in test. So I want to add to the test server a new Tomcat and JVM that match production.
As an experiment, on my desktop, I
- loaded the latest and greatest Tomcat and JVM. These represent the 'wrong' versions.
- loaded an old Tomcat with the
production system's version. - loaded an old JDK with the production
system's version. - changed the old Tomcat's config to use
port 9080. In fact I added 1000 to
all the ports except the SSL port
which we're not using. - defined a JAVA_HOME environment variable in the old Tomcat's startup scripts that points at the old JVM.
Our application will run on the old Tomcat/JVM pair. Since I didn't change the system's JAVA_HOME definition I shouldn't cause the other Tomcat to break.
On my desktop, both Tomcats seem to work properly. I don't like step #5, which feels hackish. The changes will be lost if we over-write the tomcat.
Can anyone think of anything I've missed?
Best Answer
Having different environment variables (for example different
JAVA_HOME
environment variables for different instances of your application) is entirely normal.Clearly you will have two different start up scripts for your two different tomcat environments. So hack them. I'm not sure why this presents a problem given that you'll have to have a custom start-up script for your new tomcat.