tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat 5.5: Why can't I see the applications?
Date Wed, 18 Jun 2008 20:48:52 GMT

Caldarale, Charles R wrote:
>> From: André Warnier []
>> Subject: Re: Tomcat 5.5: Why can't I see the applications?
>> And if the average Tomcat user or sysadmin were to install
>> the official Tomcat, they would after that be in front of a
>> nightmare in terms of overall system maintenance, with files
>> that are, from their point of view, "all over the place" and
>> in the "wrong" places.
> Please explain how files under the ONE Tomcat directory can be considered to be "all
over the place"?

One of the wonders of the Internet, is that one never really knows if 
the person they are corresponding with, lives on the same or a different 

Not being myself a software packager, I will answer with the little 
practical knowledge I have of the matter. I do not always know the why, 
and I do not always agree with the how, but I will describe what I find 
in my daily practice.

I am an application software developer and occasional software 
installer; my customers are generally departments of large companies, 
who run many servers.  These people work on HP, IBM, Sun, PC systems of 
all kinds, with a wide variety of operating systems, of which many 
flavours of Unix and Linux; under all of those I regularly install 
software (ours and standard software like Apache, Tomcat, Samba, Java, 
Perl, OpenSSL, etc.. as needed for the applications).
I would guess that in 95% of the cases, these systems (of which I do not 
choose the brand or configuration), have
- startup/shutdown scripts under /etc/init.d or /sbin/init.d
- configuration settings of all packages under /etc
- logfiles under /var/log or /var/adm/log
- software package (sources or binaries) under /opt or /usr
- data and/or applications variously under /var or /usr
And then there is Windows, where things are done differently, but which 
also has its interesting variations in terms of "Program 
Files"("Archivos de Programa"), "Documents and Settings" ("Dokumente und 
Einstellungen") and which call daemons, Services (at least in English).
The variations between platforms are one of those daily inconvenients 
that one is facing all the time, but also make life more interesting.

I would also say that on 95% of the machines I have to install software 
on, there are, when I arrive, already 50 packages or more installed, 
most of which having been installed using the standard software 
installation method for that platform. The tools range from SAM to rpm 
to apt and msi and several others besides.
Although there are layout differences between platforms, within one 
platform it tends to be fairly consistent, and in no case that I recall 
does this consistency consist of installing all the files belonging to 
each package, under a single root directory dedicated to that package, 
be it /usr/local/tomcat5.5 or otherwise.

System administrators in general will strongly insist that, if possible, 
I would use the same software installation tool as they use themselves, 
and the version of Tomcat that they have in their software repository 
for that type of machine, because that allows them in the future to know 
what is on their machines, and run patches and updates in a systematic 
And it is only if I can demonstate to them that the pre-packaged version 
of the software they have is not able for some reason to support the 
application that the final customer wants, that they will, reluctantly, 
allow me to install an "official version".
In which case I will generally also have to spend a lot more time 
installing the stuff, because in most cases some pre-requisite will be 
missing or be the wrong version for this bleeding-edge piece of software 
I need. Recursivity happens often.
And the sysadmin will be peering over my shoulder the whole time, just 
to check I am not installing anything nasty. And I will have to pretend 
that I understand the message "Variable xyz redeclared with incompatible 
type at line 1025 of abc.c" and find a way to fix it.
And it will cost me some extra paperwork, because I will have to write a 
"Installationsprotokoll" which explains where things are and how one can 
manage this stuff, just because it is different.
And remember, my main purpose is not to install Tomcat, it is to install 
an application that requires Tomcat.

And, you know what ? it often bothers me too, that these people would be 
so rigid.  Because it forces me to learn and understand their packaging 
system and it's quirks, and I can't just learn the "official" version of 
the package that I use on my own personal development system.

But I understand, when one of these sysadmins tells me that he is 
personally in charge of keeping 75 servers alive and well, that he would 
prefer some consistency among them, so that he can also sleep at night.

Now you go explain to one of these guys or girls why Tomcat should be 
different, and have it's own single root directory all of it's own, with 
it's settings and logfiles and software somewhere else, generally 
speaking, than the 50 packages already installed.

Let me ask you a question by the way : if all the Tomcat files are under 
a single root directory, then why not push this logic a little bit 
further, and why even bother splitting that into sub-directories ? Let's 
just put all the files directly under /usr/local/tomcat, hardcode this 
in the code, and be done with it. Think of all the parameters and specs 
one would save.  No ?

And another one : In your opinion, out of the thousands of machines 
where Tomcat is installed worldwide (I mean on this planet only), what 
do you believe is the respective proportion of the ones with an 
"official version", as compared to the ones installed from pre-packaged 
distributions ? Do you care to make a guess ?

I will now leave it to one of these fairly competent software packagers, 
to explain why one puts certain kinds of files under certain directories 
or filesystems, in preference to others.

But maybe remember that, of the people that come to this list for 
enlightenment and wisdom, probably only a small fraction are developers 
who work on their own machine and can choose where they install what on 
it, and the majority have to live with what they get.


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message