Re: Where Tomcat webapp contexts live on Debian

[Leon Rosenberg]

On Tue, Aug 22, 2017 at 10:55 PM, Emmanuel Bourg  wrote:

> On 08/16/2017 09:24 AM, 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.
>
> GCJ has been superseded by OpenJDK a lng time ago as the default
> Java runtime on Debian.
>
> > 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).
>
> FWIW, there is now a Tomcat committer maintaining the Tomcat package in
> Debian and controlling its quality. If you think there is something
> crappy about the packaging feel free to send a mail to me or to the
> debian-j...@lists.debian.org and I'll be happy to help.
>

Thank you. Mea culpa. My information seems outdated.
Leon


>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Where Tomcat webapp contexts live on Debian

[Emmanuel Bourg]

On 08/16/2017 09:24 AM, 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.

GCJ has been superseded by OpenJDK a lng time ago as the default
Java runtime on Debian.

> 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).

FWIW, there is now a Tomcat committer maintaining the Tomcat package in
Debian and controlling its quality. If you think there is something
crappy about the packaging feel free to send a mail to me or to the
debian-j...@lists.debian.org and I'll be happy to help.

Emmanuel Bourg

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Where Tomcat webapp contexts live on Debian

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Leon,

On 8/16/17 3:24 AM, 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).

Debian has tried to make Tomcat's configuration work the same way that
httpd does, with lots of little configuration files, etc. that all
contribute to a complex system. For users of a vanilla Tomcat
installation, it seems crazy. For longtime users of httpd (at least,
on Debian), it seems perfectly natural.

Debian's package structure makes sense if you think of Tomcat as
modular. It's quite reasonable for you to, for instance, NOT
install/deploy the manager application. If you download and install
the vanilla Tomcat, you have to move/rename/delete the manager
application. On Debian, it's the other way: you have to opt-into the
manager application by installing it as a separate package.

Unless Debian's package-managed version of Tomcat are actively
irritating you, I would recommend attempting to learn how they work
and get comfortable with them. The package manager will keep the
packages up-to-date and working with minimal maintenance on your part
- -- at the cost (at least, on Debian) of always being fairly delayed in
terms of version numbers. They will back-port all security fixes, but
you may be stuck on e.g. 7.0.35 for several years until you get a new
distribution update (e.g. Debian 6 -> Debian 7). This is either a
nightmare or a dream for you. Debian is insanely stable, which is
great. The downside to that is that it's *extremely* stable. :)

- -chris
> On Wed, Aug 16, 2017 at 7:43 AM, Peter Kreuser 
> 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
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmW6p0ACgkQHPApP6U8
pFg0fA//VBlLtTW6lvC54Z2Sf+9P1XzSLybW7qJVzKhZRMl3RDgLnBxNj9khV3yU
YTt+d/YWGpmBNWS7rWocP5kfWWUXh7vHZqcADWLr/hEA534X+QO/FQWDT7bIrtU8
oSO8yP6iU3fLb8vDbMUmh6szDGol0QPE8H/x6Fg8FyLhUT5EV6gaR157o8+Q9/O6
lyO1koul+XJzGvq9BsbYsJv5Dvy6gPjzEc2tRMK68Q1npNLJHOgwpMM09ppe63yR
YVaAsPlReCCGpM31Nh7vzVGOIqVUS34hbiVkheO1rD9kVKyR25S4KGhJHyS/tkHj
74z9BuO13K+YjZzQJr2SNf95O4RgIsw3C0CgdnL7hF2XY2lYOrmfFhpdoR7YMBC9
YqXXvpkxiGUbYPdiVmq8DO/DSkLfmXgaUdNlqTNqu2gXGTs84801q4ocojKBp0a2
L894scVRn4B+olkGWdf+yEaJTm5xrMvJ0gMw9s32ZFgRZet+Yz4kSnO+9nHszvfj
cvAZ/NT2NPuMXe2POv64ARupB6A9w/gTppuV/WC7gqxslZfNQwrqj+RMjXc4ypIr
/OuaRXLSI17xVb1zJ3nL/zuzfYXpzH1uVAG5eEi7GM+oUXzZjslQSdiyxnn1Ur1/
EJN2PN9yGcYCiDlv4qxJMtYc1yYFz18PSgCMCRVscTWj5aw0DeE=
=CDMF
-END PGP SIGNATURE-

-
To 

Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[tomcat]

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  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  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

Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[Peter Kreuser]

That's what I tried to say... sorry I was maybe not specific enough...

Peter

> Am 17.08.2017 um 02:29 schrieb James H. H. Lampert :
> 
>> 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?
> 
> --
> 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

Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[James H. H. Lampert]

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?

--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[tomcat]

On 16.08.2017 17:22, James H. H. Lampert wrote:

Uh, EXCUSE ME, my post was NOT a "ranting."

It was A REQUEST FOR TECHNICAL INFORMATION.

The unusual way Tomcat is organized if installed via an "apt-get" from Debian's 
repository
is a given. I made OBSERVATIONS about it, by way of framing my question. While 
I could not
manage to keep my opinions on that organization completely to myself, I DID 
endeavor to
restrain those opinions.

The question is, *HOW* does Tomcat know where to find webapp contexts in all 
those
different places? Obviously, SOMETHING, presumably something in a configuration 
file, has
to tell it to look for them in a bunch of different places, but WHAT, and WHERE?



Hi.
I did not mean to suggest that /your/ post was a ranting, and I understood perfectly that 
you just wanted to know. My purpose was to address some other posts, in response to yours 
but also many previous similar ones, which repeatedly go in the direction of "install a 
standard Tomcat" as a response to questions like yours. (That's also why I prefixed my 
intervention with [OT]).

My apologies if this was not clear.
(But no need to SHOUT either)

Kontantin started to answer your question.
See also the last (non-PS) paragraph of my previous post, to understand why we cannot 
always answer questions quickly and in a simple way.
The problem in this case is : your question looks simple in appearance; but the full 
answer /is/ really complex, and involves many variations, some of which have to do with 
the platform, some with the scripts which on that platform start Tomcat, some with the 
Tomcat configuration files, some with the Tomcat version, some with the applications 
themselves etc.
So the "SOMETHING" that you want to find out, is not /one/ thing, but /many/ things which 
cooperate (or not) to provide the full answer.


I could tell you exactly how it works on /my/ Debian systems, with /my/ version of Debian, 
with /my/ version of Java, /my/ version of Tomcat and /my/ applications. But unless you 
happened to have the same as mine for everything, that would not be entirely applicable to 
your situation.
We all had to go through the same exercise, to find out how Tomcat and its applications 
were started on our particular platform of choice, and we all have to redo that same 
exercise from time to time, as things keep changing.


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.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[James H. H. Lampert]

On 8/16/17, 10:13 AM, Konstantin Kolinko wrote:


I see that you mentioned that you are using Tomcat 7.

See [1] for how contexts are defined and [2] for attributes "appBase"
and "xmlBase" of a Host.

. . .

Thanks. I'll be looking into the links you sent me later today, and if I 
have any further questions, they'll probably be more specific, and less 
likely to be misread as an off-topic rant.


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[Konstantin Kolinko]

2017-08-16 18:22 GMT+03:00 James H. H. Lampert :
> Uh, EXCUSE ME, my post was NOT a "ranting."
>
> It was A REQUEST FOR TECHNICAL INFORMATION.
>
> The unusual way Tomcat is organized if installed via an "apt-get" from
> Debian's repository is a given. I made OBSERVATIONS about it, by way of
> framing my question. While I could not manage to keep my opinions on that
> organization completely to myself, I DID endeavor to restrain those
> opinions.
>
> The question is, *HOW* does Tomcat know where to find webapp contexts in all
> those different places? Obviously, SOMETHING, presumably something in a
> configuration file, has to tell it to look for them in a bunch of different
> places, but WHAT, and WHERE?

I see that you mentioned that you are using Tomcat 7.

See [1] for how contexts are defined and [2] for attributes "appBase"
and "xmlBase" of a Host.


[1] 
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context
[2] http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Common_Attributes

Generally, context are created in three ways:
1) when Tomcat starts and server.xml is parsed

If there are any explicit "Context" elements in a Host, a Context is
created for each.

2) by auto-deployment logic that runs when Tomcat starts (aka
deployOnStartup) or runs periodically (aka autoDeploy)

It looks for files in Host's xmlBase (I see somewhere it is called
"configBase") and directories in Host's appBase directory. See [3]

3) programmatically via API, JMX calls
- via Tomcat Manager web application,
by org.apache.catalina.startup.UserConfig listener [4],
etc.

[3] 
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment
[4] 
http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#UserConfig_-_org.apache.catalina.startup.UserConfig

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)

[James H. H. Lampert]

Uh, EXCUSE ME, my post was NOT a "ranting."

It was A REQUEST FOR TECHNICAL INFORMATION.

The unusual way Tomcat is organized if installed via an "apt-get" from 
Debian's repository is a given. I made OBSERVATIONS about it, by way of 
framing my question. While I could not manage to keep my opinions on 
that organization completely to myself, I DID endeavor to restrain those 
opinions.


The question is, *HOW* does Tomcat know where to find webapp contexts in 
all those different places? Obviously, SOMETHING, presumably something 
in a configuration file, has to tell it to look for them in a bunch of 
different places, but WHAT, and WHERE?


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Where Tomcat webapp contexts live on Debian

[Mark H. Wood]

Yes, many distributions lay out Tomcat the same way as every other
daemon is installed in Unix (executables in /usr, volatile data in
/var, configuration in /etc) and the startup scripts set CATALINA_HOME
and CATALINA_BASE to make that happen.  If you look in CATALINA_BASE,
you may find symlinks like conf -> /etc/tomcat-7, as Gentoo does it,
to explain the few things that can't be relocated by configuration.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: [OT] Re: Where Tomcat webapp contexts live on Debian

[Leon Rosenberg]

Hi Andre et al,

I've dealt with a lot of different servers and OSes over the years, and my
'professional' advice to everyone maintaining a java/web application would
be to create a root level directory and install everything they rely on
there and maintain it themselves. This includes especially java, tomcat,
databases (especially modern ones like mongo or crate), search engines etc.
Leave the OS basics and security stuff to the OS maintainers and do
everything else by yourself. With puppet, chef or ansible maintaining many
servers is not a big issue anymore, and most hosting providers will have
support for this or that automation technique. Or go straight for docker.

Just two weeks ago I had a pleasure of watching someone loosing his
production site, cause auto-upgrade just screwed their crate.io
installation.

regards
Leon

P.S. I haven't used debian for 4-5 years now, but I know that back in the
days they considered stuff stable after two years without major problems,
which is past EOL for modern software. This approach is surely ok for
things like routers or mail servers, but you don't want to stick to a two
year old version of mongo or tomcat.





On Wed, Aug 16, 2017 at 11:27 AM, André Warnier (tomcat) 
wrote:

> 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 

[OT] Re: Where Tomcat webapp contexts live on Debian

[tomcat]

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  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 

Re: Where Tomcat webapp contexts live on Debian

[Leon Rosenberg]

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  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
>
>

Re: Where Tomcat webapp contexts live on Debian

[Peter Kreuser]

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 :
> 
> 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

Where Tomcat webapp contexts live on Debian

[James H. H. Lampert]

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