On 17.08.2017 02:29, James H. H. Lampert wrote:
On 8/16/17, 11:43 AM, André Warnier (tomcat) wrote:
, , ,
So as a start, look at /etc/init.d/tomcat7 on your system, and check
what other files this calls/references. One important thing here, is
what the environment variable CATALINA_BASE ends up containing.
Ok. This is starting to look interesting. CATALINA_BASE seems to be set to
/var/lib/tomcat7.
And when I do an "ls -l" on /var/lib/tomcat7, I find that "conf" is a symbolic
link to
/etc/tomcat7, and "logs" and "work" are also symbolic links.
Now THIS is interesting: in /etc/tomcat7/Catalina/localhost, I find a couple of
files,
"manager.xml" and "host-manager.xml," and both of them contain a "Context" tag
with a
docBase pointing to where the corresponding contexts live.
Am I getting any closer to understanding how this works?
Yes, but don't go too fast, or you'll get confused.
Forget for now the "manager" and "host manager", and follow the track to your
own webapps.
CATALINA_BASE points to the "root directory" of this Tomcat running instance. (There could
be more, each with its own CATALINA_BASE).
In CATALINA_BASE/conf, is where Tomcat is expecting to find its main
configuration files.
The file "server.xml" there is the main configuration file for this Tomcat
running instance.
Inside that file, is a <Host> tag, which specifies the (relative to CATALINA_BASE)
location of the place where the normal webapps (of this instance) should be found.
(There can also be several <Host> tags, one per "virtual host", but that's for another
day. Let's assume for now that there is just one there, and that's the default Host).
Unlike Apache httpd e.g., the (relative) top of the webapps directory (which may be called
the "default webapp") is not "/".
For Tomcat, it is the (webapps_dir)/ROOT/ (in capitals).
And other web applications live in parallel directories there, like
(webapps_dir)/app1/
(webapps_dir)/app2/
(webapps_dir)/app3/
etc..
Each of these "applications" has its own expected structure, with sub-directories such as
"WEB-INF", "META-INF" etc.
And at this point, you should go back to the pointers given by Konstantion earlier, and
read these pages to understand what this all means.
The thing to understand is : Tomcat has its own "expectations" as to how this is all
laid-out on disk (many of these expectations being due to the Java Servlet Specification).
But Linux Debian has a different schema, across all software packages, where it
expects e.g.
- configuration files to be under "/etc"
- logfiles to be under "/var/log"
- shared executable code to be under "/usr/share"
etc.
All that these Debian/apt directory links do, is to try to "coerce" Tomcat into fitting
into the Debian classic disk layout, so that system administrators would find things where
they generally expect them to be. (And not like where the Tomcat developers, or the Apache
httpd developers, or the logrotate developers each expect their own personal little
package to be)(apologies for this to the respective developer's teams ;-) ).
That just makes it much easier for sysadmins e.g., because they know for example that if
they backup the "/etc" directory, they have in one go *all* the configuration files of
*all* the installed packages. And they now that they have to watch the filesystem
"/var/log" for space, because that is where *all* the installed packages write their
logfiles. And they know that for example "/usr/share" contains only code, and should not
grow uncontrollably because of some rogue application writing its data files there.
Another way of looking at this, is not to say that "Debian packagers put Tomcat files all
over the place", but rather that
- individual software packages normally put their files all over the place (if you
consider a set of packages, not just one)
- the Debian packagers try to restore some order in this chaos, and to put things where
they are supposed to be, from a global, whole system point of view
(And similarly - but of course a bit differently - for other Linux distributions. Where
would be the fun if they all did it the same way ?).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
