In my current project, we’re using Apache Tomat and Eclipse as the IDE. The Java Platform is Amazon Corretto 11. I’m using macOS and the working setup before upgrading was this:
- Tomcat is installed using Homebrew:
brew install tomcat
- Java was installed by downloading the package (see link above) and running the installer.
- I have set
.zprofile so the right Java version is used.
- I’d start Tomcat from the command line and our tests from inside Eclipse.
This worked nicely.
After The Upgrade
The upgrade went smoothly for most of the software I am using: Other IDEs, installations of Ruby, Elixir, databases, REST clients, git, etc. all continued to work nicely.
The tests however failed in an interesting way: While basic REST calls worked (e.g. a GET request to retrieve version info), the tests that were using the actual functionality were receiving a plain “Internal Server Error” from Tomcat and the application logs showed some
getContext method that ended up receiving
null instead of the expected object.
Running the same tests on the same machine using the way the tests are started in CI still worked well. The difference between running from within the IDE & the command line: The command line starts Tomcat and runs the tests against that (and then stops Tomcat), while the IDE uses the already running Tomcat. — Aha!
Tomcat logs several environment variables it’s using when it starts, among them
And this environment variable pointed to another Java environment, that came from a different source, had a different Java version, and furthermore was (obviously) incompatible with the Java environment set up in JAVA_HOME.
JRE_HOME to the same Java environment solved the problem and tests are running just fine again. Phew!
The documentation has a section about this (docs can be so useful!):
(3.2) Set JRE_HOME or JAVA_HOME (required)
These variables are used to specify location of a Java Runtime
Environment or of a Java Development Kit that is used to start Tomcat.
The JRE_HOME variable is used to specify location of a JRE. The JAVA_HOME
variable is used to specify location of a JDK.
Using JAVA_HOME provides access to certain additional startup options that
are not allowed when JRE_HOME is used.
If both JRE_HOME and JAVA_HOME are specified, JRE_HOME is used.
The recommended place to specify these variables is a “setenv” script. See…/tomcat/9.0.39/libexec/webapps/docs/RUNNING.txt in my Tomcat installation
Furthermore, there are comments explaining what to expect with respect to
# JRE_HOME Must point at your Java Runtime installation.…/9.0.39/libexec/bin/catalina.sh. lns 61 ff
# Defaults to JAVA_HOME if empty. If JRE_HOME and JAVA_HOME
# are both set, JRE_HOME is used.
It’s still not entirely clear what caused this behaviour.
If you have an idea or ran into a similar problem, I’d definitely like to known about it.