Re: Where Tomcat webapp contexts live on Debian
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
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
-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 unsubscribe, e-mail: use
Re: Where Tomcat webapp contexts live on Debian (NOT off-topic; A LEGITIMATE TECHNICAL QUESTION)
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)
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)
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)
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)
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)
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)
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
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
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 would be costly and
[OT] Re: Where Tomcat webapp contexts live on Debian
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 question: who did this se
Re: Where Tomcat webapp contexts live on Debian
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
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
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