monline

For future Eclipse versions: the solution is documented in the help in the "Platform Plug-in Developer Guide" / "Programmer's Guide" / "User assistance support" / "Help" / "Deploying the information center as a Web Archive" section (this is only available in your Eclipse IDE if you've installed the "Eclipse Platform SDK" component).

Essentially you've to unpack a JAR, download some extra component (another JAR) and build a WAR file using Eclipse. Then this WAR can be deployed to any application server, eg. a Tomcat and you've got a local copy of the Eclipse help center.

Reading through the Servlet API documentation it's quite probable that you'll stumble on a couple of questions you cannot answer ... at least not based on the docs. I always wondered how exactly Tomcat handles the various elements of a webapp that we define in the web.xml deployment descriptor file. To lift all doubts, I've written a small webapp that logs all aspects of the startup process of a Tomcat context. I've chosen to use the good old standard error (System.err.println()), because loggers would have added just unnecessary dependencies, configuration and complications.

Update (2011.02.11): The original post proved to be a false alarm. However I'll keep it, because there's valuable information in the comments.

I've stumbled on an interesting behaviour of Tomcat (5.5.26): if you implement the javax.servlet.http.HttpSessionListener interface in a class and define a listener with this class in your web.xml, then your sessionCreated() function will be called on a session only at the first attempt to store some data in the session and not when the session is actually created! You can easily test this for yourself.

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.