At this moment I thought of a glitch in the server setup but some nagging hours later I realized that my so clever solution was a dirty hack. Which works in a Microsoft Windows environment, but refuses to work on in a Linux environment.
Ok, I have to confess, that I wasn't really happy with my first solution in the end. Renaming JARs to provide the correct order of class loading always leaves a bad taste. But at that moment I was happy, no other solution was in sight and I had absolutly no time.

Some days ago I posted a blog entry about using Glassfish v2 EJBs with the Tomcat. At this moment I thought that I solved the problems, but last week we were setting our testing evironment on a Debian Linux box and the problems reoccured.

At this moment I thought of a glitch in the server setup but some nagging hours later I realized that my so clever solution was a dirty hack. Which works in a Microsoft Windows environment, but refuses to work on in a Linux environment.
Ok, I have to confess, that I wasn't really happy with my first solution in the end. Renaming JARs to provide the correct order of class loading always leaves a bad taste. But at that moment I was happy, no other solution was in sight and I had absolutly no time.

Enough with apologies at this moment, we were late setting up the testing environment too and there was work to do. So I decided to take a different approach and tried to find out some more about the classloading of Tomcat 6. One of my primary questions was: "Why did the Tomcat 6 developers removed the different classloading directories?"

The answer suprised me more, than I expected! After using Google for a while, trying to find out more about the differences in classloading between Tomcat 5.5 and Tomcat 6, I stumbled across a small file: The catalina.properties. This file revealed the secrets of the differnces in classloading between these two Tomcat version. The simple and quite beautyful answer is: There aren't any real differences. The distributions have different default settings, but the classloading mechanism is quite the same. At this point I am getting some more cautious than the last time. The two mechanisms are the same, as far I can judge it from my appication developer/deployer point of view

So what is this catalina.properties all about? The catalina.properties - as I understand it - controls some major classloading and security issues while bootstrapping the Tomcat web container. It has three (for my problem) relevant entries:

common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
[...]
server.loader=
[...]
shared.loader=

These three entries are controlling three classloader in Tomcats classloader hierachy. The server classloader, the common classloader and the shared classloader. The server classloader is resopnsible for loading the libraries of the tomcat server. It is not set in the Tomcat 6 default distribution and will default to the common classloader which will load the server related classes now. The common classloader is responsible for loading classes common to the tomcat installation. Which are in the Tomcat 6 the server classes as well as addiontional classes like the JavaMail API oder some database driver classes (if you are configuring them with JNDI i.e.). The last classloader is the shared classloader which may load classes which may be shared between different web applications. This is the place where the Amis blog entry suggests the glassfish JARs to be placed, but which I hadn't found in the Tomcat 6 distribution.

After I discovered the secrets of the catalina.properties it took me half an hour to create a shared/lib directory in my TOMCAT_BASE and adapting the catalina.properties file. Now I had the proper place for my Glassfish files and it worked nearly instantly. Good to know that you can make the integration of Glassfish EJB and the Tomcat 6 in a proper way and also good to know about this tiny little classloading tricks of the Tomcat 6

As you say in german: "Kaum macht man es richtig, dann geht's!" (If you starting to do it the right way it works)

So well, my first blog post with some contentent. I am quite excited and somewhat terrified, I really hope my english will be good enough.

So what is this ETag thing. I am working since 1998 in the web business but I came across ETags some weeks ago when some of my customers starting to worry about their perfomace. Don't get me wrong, out apllication worked - as always - fine, but some pages where slower as the equivalent pages at the websites of their competitors. We checked our monitoring data, it's always good to know of the webstite performed on yesterday, yesterweek or yestermonth, but were unable to find some issues. So we went from the server to the protocol and the client and checked some static and dynamic pages. As I was taking a closer look at a static webpage I stumbled over a HTTP header which I didn't know: ETag.

What is this ETag thingy? Why do only static pages have it? Okay to get this clear, I have to reveal some secrets about our customers setup. It runs on an Apache webserver who delegates the dynamic webpages to a Tomcat servlet container. They dynamic content will be generated there by some servlets and JSP. But this is also the solution. The static page was deliviered by the Apache HTTPD and the server adds the ETag header to all files.

So again what is this ETag thingy? What is it good for? Something I learned some years ago: It's always a good Idea to go to the source. In this case its the RFC 2616 in Section 14.19 the ETag HTTP header field is defined. But nowadays it's quite okay if you check Wikipedia first and at least a Wikipedia you will get a link to the RFC.

I confess it took a little while for me to understand what the ETag is good for. The web server may create an entity tag for the requested entity. This tag acts like some kind of content identifier or a kind of version number of the content. The Browser can use this information at a later time, when the entity (URL) is requested again send the ETag value in the "If-Match" or more likely the "If-None-Match" header field. If the browser does so, the server may evaluate the header and send a simple 304 (Not Modified) response instead of a 200 (OK) response and the data of the entity. The whole thing works basically equally to the "Last-Modified" and "If-Modified-Since" or "If-Unmodified-Since" mechanism. So why to we need this redundancy?

I am not that deep into the specification process of the HTTP protocol, but I am working a while with distrubuted web applications. Sometimes you simply need to mess around with the latest modification date of a file to get some rsync-ing right or something like that. In general the bad news is: The last modified date is not that reliable if you want to determine if a file is still the same. So this ETag thingy seems to be a good solution to this.

In real life nothing is this easy. The Apache web server calculates the ETag value out of the INode of the file, the last modified date and the size of the file. This is quite awkward if you have more than one HTTPD instance delivering the same file (i.e. if you use DNS round robin load balancing). It would be a small miracle if the file gets an INode with the same id on the different instances. So the ETag mechanism may get some kind of useless, so that Yahoo! recommends in their Best Practices for Speeding Up Your Web Site to deactivate the mechanism. The logic behind this recommendation is: A useless check done is a waste of time. I am not totally lucky with this but Yahoo! has some kind of point with it.

Luckily you can configure the ETag creation in the Apache web server with the FileETag directive. So may use only the modification time (MTime) and the file size (Size) for the ETag creation. This should work out quite well and if you can keep the last modified date in sync between the your web server instances the mechanism should work properly.

Okay I hope someone else reads this and may find it useful. At the moment I am investigating some ETag and last modified header issues with servlets and JSP. I guess I will try to blog about it soon ...