0

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

  1. loaded the latest and greatest Tomcat and JVM. These represent the 'wrong' versions.
  2. loaded an old Tomcat with the production system's version.
  3. loaded an old JDK with the production system's version.
  4. 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.
  5. 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?

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
1
  • I'm also not sure why this might present a problem which is why I asked. It running in production now. Commented Oct 6, 2010 at 12:26
0

Virtualise - it's exactly what this kind of problem calls for.

Improve this answer
2
  • Do you mean add virtual machines? The admin tells me the test server doesn't have the resources. However, we're moving to that in the near future. Commented Sep 29, 2010 at 14:57
  • Yeah, exactly that, one of the best uses of virtualisation is for testing code on different underlying code. In fact it's the best way of testing because you can snapshot a virtual server, install new code on it then test and revert back to the snapshot knowing that you've not left anything lying around from the subsequent testing. Commented Sep 29, 2010 at 15:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.