GCJ-based Tomcat in Fedora - avoid it I was playing with Fedora core, and discovered they do include tomcat. What is really interesting is that it is compiled to native code using GCJ. I always liked GCJ and I believe it is very important for all java projects to be able to compile and run with Classpath and gcj - so I decided to take a look. It turned to be a horrible experience, adding fuel to my frustration on the current state of open source packagers.

First, in a classical FHS tradition, they did a total mess with the layout of the files. Part of tomcat is in /usr/share/tomcat, including some webapps, some other are in /var/lib/tomcat - like /var/lib/tomcat/examples/. Configuration is in /etc/tomcat - but also in /etc/sysconfig/tomcat. And the startup script is /etc/init.d/tomcat - and so far I couldn't figure how to start tomcat as a regular user, it seems some classpath is missing. Not to mention that it looks for some stuff in $HOME/server/lib. I could rant a lot more about this - FHS is the worst thing that happened for linux, by far - it is enough underspecified to allow distributors to lock in by placing files in their own way, and enough buzzword to fool people into accepting this crap.  But that's another story.

The first time it didn't start because my hostname wasn't fully qualified name. No real message, but I found something in /var/log/tomcat/tomcat.out. I fixed that, and then started as root and ran it.

After starting tomcat as root, I did the usual - run "ab -n 10000 -c 80 " on the hello world servlet. It stopped after about 900 requests with "out of file descriptor" error. After that no request worked.

What would a regular user think about tomcat if he install Fedora and the included tomcat ? How could anyone who is familiar with tomcat help them - in the file mess that they create ?

Again, I know that the license allows them to redistribute tomcat - and somehow the accepted practice is that "redistribution" can mean completely changing the expected directory structure and behavior. I know the license doesn't require them to test it or make sure it is comparable in stability and quality with the "real" distribution. But this is very, very wrong - and I think it is the duty of the software maintainers to at least explain that even if it is called "tomcat-4.1.27" - it is not the real tomcat.

Maybe if all OS projects would start requiring that a certain layout and quality is maintained before allowing distributors to user their project name - then the current distribution nightmare would stop. All users are hurt - it is a real lock in that redistributors have succeeded by creating their own variations. The result is that lots of companies can only support few distributions, making it harder to switch.

Most projects are hurt by the fragmentation and chaos in the binary distributions. Any attempt to write add-ons or scripts or provide basic support for a project will be far harder - unless you pick one or two distributions and exclude the other ( thus amplifying the problem ). In the end - I think it is entirely the fault of open source projects for not taking seriously the distribution of their code to users. Some may believe that distributions are helping them by generating the binaries and providing some form of support - but the price is too big, it makes real support far harder and sends the wrong message to users.

The alternative - if projects start distributing their own RPM/.DEB/.TGZ, or include link to "recommended" binaries ( and recommend people to avoid the bad ones ).
Posted by costin at May 15, 2004 11:20 PM