When you upgrade an existing Tomcat 5.0.19 server to Tomcat 5.0.24+, you may have problems getting the server to come up without adding jmx.jar explicitly to the CLASSPATH. This happens only after a badly applied upgrade. The "fix" to make sure this doesn't happen is to add jmx.jar to the CLASSPATH after commons-logging-api.jar. Without this fix, you may see this message in catalina.out: Bootstrap: Class loader creation threw exception java.lang.NoClassDefFoundError: javax/management/MBeanServerFactory at org.apache.catalina.startup.Bootstrap.createClassLoader (Bootstrap.java:165) at org.apache.catalina.startup.Bootstrap.initClassLoaders (Bootstrap.java:104) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:193) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:270) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.daemon.support.DaemonLoader.load (DaemonLoader.java:201) Since you can fix the configuration problem in the server, adding jmx.jar explicitly to the CLASSPATH is a minor bug fix, although it might provide a big hint to people who are upgrading Tomcat 5.0.19 servers. Typically this error means someone may have moved jmx.jar to its previous resting place (i.e., $CATALINA_HOME/common/lib) because they thought that's where it was supposed to go, so you can just restore a correct copy of jmx.jar to bin to recover from this problem. This could be avoided by a documentation update instead of a code change.
What documentation update would you suggest?
I think originally this worked by having inside the manifest of bootstrap.jar the line Class-Path: jmx.jar commons-daemon.jar commons-logging-api.jar and putting jmx.jar to the bin directory.
The manifest for bootstrap.jar has not changed: it still contains jmx.jar before commons-logging in the classpath line. Also, jmx.jar is still in the bin directory, so that hasn't changed either.
I would update the change logs to add a more explicit comment about jmx.jar residing in bin instead of common/lib. Anything more than that is probably overkill since you only get this problem when you do something odd to the install (like moving the jmx.jar file into common/lib again, etc.). Adding jmx.jar to the startup scripts might help make it clear that the startup has JMX dependencies.
It was already in the changelog (v5.0.20), but I don't think that's visible enough, so I've added the following to the RELEASE NOTES file, in the standard APIs section: Please note that the JMX API is available to applications as well. The jmx.jar file used to be located in the common/lib directory, but was moved to the bin directory as part of the Tomcat 5.0.20 release. The jmx.jar is in Tomcat's bootstrap classpath (included via the Class Path line in bootstrap.jar's manifest). This will of course be visible and available starting with the next release, 5.0.26.
I just downloaded 5.0.27 binary and it still occurs: sltam@delta:~/jakarta-tomcat-5.0.27$ bin/catalina.sh run Using CATALINA_BASE: /home/sltam/jakarta-tomcat-5.0.27 Using CATALINA_HOME: /home/sltam/jakarta-tomcat-5.0.27 Using CATALINA_TMPDIR: /home/sltam/jakarta-tomcat-5.0.27/temp Using JAVA_HOME: /usr/lib/kaffe Due to new licensing guidelines mandated by the Apache Software Foundation Board of Directors, a JMX implementation can no longer be distributed with the Apache Tomcat binaries. As a result, you must download a JMX 1.2 implementation (such as the Sun Reference Implementation) and copy the JAR containing the API and implementation of the JMX specification to: ${catalina.home}/bin/jmx.jar sltam@delta:~/jakarta-tomcat-5.0.27$ JDK: kaffe 1.1.5 branch System: Debian Linux unstable i686 Adding this to catalina.sh solves: CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/jmx.jar
Tomcat requires a JDK that understands Jar Class Path directives, which your kaffe 1.1.5 apparently doesn't. If your JDK doesn't understand these directives, you may have to manually modify a number of things, not just catalina.sh, as you undoubtedly know by now.