This being a Tomcat list, and Tomcat being java, it is rather to be expected that many
people on this list would tend to have a rather Tomcat-specific, and rather Java-specific
view of the world. And the fact that most Linux distributions have their own way of
packaging software, and installing it according to their own logic, does not always make
it easy for others than the supplicant, to provide meaningful help.
This being said, in the real world, Tomcat/Java applications often have to share a host
with many other applications/languages, and managing such hosts is generally the task of
sysadmins, who many times don't even get to choose the OS of the host which they have to
administer and keep running.
For these people, it is often impossible to manage each host and software package
individually, and they have to use tools appropriate for the job of managing multiple
hosts with multiple applications each. Some of these tools are the corresponding
platforms' "software package managers", working from corresponding "software package
repositories" containing (hopefully) software packages in versions which have been
previously tested to be "production-ready", secure, AND not conflicting with other
software packages likely to be in use on the same hosts.
These tools sometimes install bits and pieces of some packages, in places which do not
appear to the single-package specialist as being "natural". But generally, they do make
sense if one considers the whole host, its multiplicity of packages, and administrative
constraints (such as backups, disk space allocation, logfiles management, security-related
updates etc).
Independently of this, I for one also have corporate customers who have their own rules,
and won't let me install or configure some things in some places of the filesystem, and
insist on them being where their own rules dictate (/opt, /var, /src, /srv, /mnt, you name
it).
So I believe that regular rantings on this list about this or that distribution, and how
it decides which version of the product it includes, and where it actually installs the
various parts, are in the end time-consuming and rather counter-productive.
Because that is just the way the world is, and most of us cannot change it
easily.
Mercifully, Tomcat is designed in such a way that it /can/ be installed and run according
to almost any architecture and layout. (As long as one has access to its configuration
files, which is also not always a given).
On this list, I believe that we try to help anyone who has a problem with
Tomcat.
Sometimes we cannot do that, or can only do it uneasily, because the problem may be due to
a configuration or layout issue which we cannot guess, or cannot reproduce.
/That/ is why we would sometimes /recommend/ to the supplicant to try to install a
"vanilla" version of Tomcat fom the Tomcat website, and check if they can reproduce the
issue there. But we cannot /force/ the supplicant to do that, and sometimes they may not
be able to do that for whatever reason.
In such cases, we may sometimes be unable to help, but that also is the real world, which
requesters on a volunteer-manned help forum for a package that is open-source and free,
should also understand.
P.S. Speaking professionally : we develop and run our applications on our own servers
(Linux, Debian) as well as on some customer servers (Debian, RedHat, Suse, and even
Windows). I do not remember why we initially chose Debian as our main platform, but we now
have some 40 servers with it. We are "comfortable" with it (today as well as previously),
we have no particular problem with it, and it would be costly and time-consuming to change
to another main platform. Over time, we have learned how Debian (and other platforms)
install things and where, and we have documented it. Our usage of Tomcat may be simple,
but I cannot recall exactly how many years ago we last had a Tomcat issue which had to do
with how Debian installs it on the disk.
Other people's mileage may vary, but I thought it was worth mentioning this, to provide a
balancing opinion.
On 16.08.2017 09:24, Leon Rosenberg wrote:
Debian has a long tradition of doing things in a very special way when it
comes to java. Long enough they shipped GnuJ as standard JVM with a debian
distribution, a piece of garbage that wasn't able to start simplest of java
programs.
But there has been an as long tradition to reply to every question about
tomcat behaviour on a specific distribution by suggesting to throw the crap
away and download the vanilla tomcat form the one and only legal source ;-)
(at least in the past, to which debian belongs).
regards
Leon
On Wed, Aug 16, 2017 at 7:43 AM, Peter Kreuser <l...@kreuser.name> wrote:
I'd assume the service that starts tomcat sets the bin-Dir, that contains
a setenv.sh, that has the CATALINA_HOME and BASE env-Varaibles, where you
find the context-Files that have a docbase.
I'd like to repeat the question: who did this setup?
Peter Kreuser
Am 15.08.2017 um 23:45 schrieb James H. H. Lampert <
jam...@touchtonecorp.com>:
I think I've mentioned before that I have a Tomcat server on a Google
Compute Debian instance, that I installed with an "apt-get," rather than
from an Apache download.
I had to apt-get manager separately, which is odd to begin with.
And things ended up in unexpected places.
Some stuff (like the Catalina directory) wound up in /etc/tomcat7. Other
stuff (like the bin and lib directories) wound up in /usr/share/tomcat7.
But the weirdest thing is where the webapp contexts wound up. The
default ROOT context (which doesn't look quite like the default ROOT
context of anything I've installed from an Apache download) is in
/var/lib/tomcat7/webapps/ROOT. But the manager and host-manager webapps are
in /usr/share/tomcat7-admin/manager and /usr/share/tomcat7-admin/host-
manager.
Setting aside any questions of why whoever set this up for Debian did it
this way, all of this still raises a very big question:
How is Tomcat finding all of this?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
