monline

While creating a Java web application you'll most probably use various libraries pre-packaged into JAR files. And of course you'll create several JARs for your own code as well. However some of these JARs might share the same classes and most of the time there's no guarantee on from which JAR a class is loaded. Your best bet is to make sure that each class (that you need) is present only in one JAR in you lib folder. To find classes that occur more than once in a webapp library folder, I've written a short shellscript.

Tomcat's class loading can be tricky some times. If you search on class loading problems, you'll find myriads of posts on blogs, forums, etc. And it's not just because people don't know how it works (which is actually well documented), but because it sometimes doesn't work. There've been bugs in Tomcat's class loading and even if it's working as expected, it can give you a hard time to track down what's actually happening behind the scene.

First of all, where to find JConsole: it's part of Sun's JDK. Both the Windows and the Linux versions of Sun's JDK (not JRE!) contain JConsole, so it's quite trivial to get. Second: enable JMX remote connections in your Tomcat. If you're running Tomcat on a Debian or Ubuntu server, then you've to add the required startup parameters to the /etc/default/tomcat5.5 file to the CATALINA_OPTS variable. Eg.
(Note: the -Djava.awt.headless=true -Xmx128M -server parameters are there by default).

Now start JConsole (if you're using an Ubuntu desktop and installed the sun-java5-jdk package, then you'll find a "Sun Java 5.0 Console" item in your Applications / System Tools menu), select the Remote tab, enter hostname and port number (7091 in the above example) and connect. You might still get connection error though.

I've found a thread about the problem, but no solution there. With a little help from Sysinternal's Process Monitor I could find out that the Tomcat installer misses the client subdirectory in the JRE\bin dir and the jvm.dll file inside that dir. In case of Sun's JRE the bin dir indeed contains a client\jvm.dll, but in case of JRockit that dir is called jrockit. Thus you can work around the issue by renaming the jrockit directory inside JRE/bin, do the install, then rename it back. However if you intend to keep the original name, then after the installation you've to alter the JVM path in the Tomcat configuration (the little app. sitting in the system tray) too to match the real JVM path.

In a Linux/Unix environment send a QUIT signal to the JVM process.
Eg.

On a Windows server there's a utility named "Monitor Tomcat" in the Start Menu (under "Apache Tomcat ..." group. Start it, right-click its icon in the system tray and select "Thread dump". This will generate a dump in Tomcat's log directory with a filename like "jakarta_service_yyyymmdd.log".

There's a version.sh shell-script in the "bin" subdirectory of the Tomcat home dir. You'll need to set the JAVA_HOME variable prior to running it.