On the subject of "Newbie-friendly", I think Tomcat would be a whole lot more friendly if CATALINA_HOME and CATALINA_BASE were always totally separate with a minimum of overlap.
Although I used Tomcat quite a lot years ago I still consider myself a Tomcat Newbie, mostly because configuration always took days or weeks longer than is reasonable. Now I'm back to Tomcat after years of having it easy using GlassFish. The files might be different now but the grief with configuration is still the same. I've been through numerous configurations with various versions of Tomcat 7 and 8 the furthest I've got is getting a database connection to work. Now having created a minimal CATALINA_BASE I've jumped a few steps back and it won't start. I am sure many of the problems would evaporate if only there were built in and permanent clarity over the separation between CATALINA_HOME and CATALINA_BASE. Yes, I've read RUNNING.TXT and I'm left wondering why do I have a catalina class not found if all the tomcat jar files are in CATALINA_HOME/lib Using CATALINA_BASE: "C:\tomcat8catalina_base" Using CATALINA_HOME: "C:\tomcat809" Using CATALINA_TMPDIR: "C:\tomcat8catalina_base\temp" Using JRE_HOME: "C:\jdk1.7.0_55" Using CLASSPATH: "C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat-juli.jar" Listening for transport dt_shmem at address: tomcat_shared_memory_id 03-Nov-2014 17:45:50.410 SEVERE [main] org.apache.tomcat.util.digester.Digester.startElement Begin event threw exception java.lang.ClassNotFoundException: org.apache.catalina.startup.VersionLoggerListener All these experiments are done running Tomcat under NetBeans so perhaps part of my issue is with NetBeans. The CLASSPATH shown above is a bit on the short side, is it meant to be so short ? Vince -----Original Message----- From: Webb, Vince (TR Technology) Sent: 17 October 2014 10:17 To: 'Tomcat Users List' Subject: RE: Separation of CATALINA_HOME and CATALINA_BASE I don’t see their separation as being incompatible with running from a default shell or batch file. It already figures out where to use for CATALINA_HOME, the default place for CATALINA_BASE could be a standard difference from CATALINA_HOME, for example: CATALINA_BASE=$CATALINA_HOME/../catalina_base I imagine this could work OK directly from an extracted tar distribution as it does now. I don't know how much difficulty this would cause for IDE plugin's, they might end up needing less code rather than more. Vince -----Original Message----- From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID] Sent: 16 October 2014 20:07 To: Tomcat Users List Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin, On 10/16/2014 11:52 AM, Konstantin Kolinko wrote: > 2014-10-16 22:11 GMT+04:00 <vince.w...@thomsonreuters.com>: >> Hello I'm coming back to Tomcat after years using GlassFish. The >> little that I ever understood of Tomcat 3, 4 and 5 is now decidedly >> rusty so I've been reading Tomcat 7's RUNNING.txt with interest. >> >> The section under the heading: Advanced Configuration - Multiple >> Tomcat Instances Looks interesting to me even though I have no desire >> to run multiple instances. >> >> Configuring CATALINA_HOME and CATALINA_BASE to be separate >> directories looks to me like such a winning idea that I'm left >> wondering, why the default TOMCAT installation puts all that stuff in >> one directory ? >> >> I have not looked to see if Tomcat 8 separates them. > > 1) The default distributive is friendly to newbies. If you just run > startup.sh (startup.bat) it assumes that CATALINA_HOME == > CATALINA_BASE == its parent directory and starts successfully. > > If you separate "home" and "base" you have to pass them as environment > variables to the scripts. That requires a bit more of configuration > from the users. > > 2) On productive systems you usually configure CATALINA_BASE once > (your site) and install a new CATALINA_HOME with each point release. > > Even if some files such as "webapps" are not used in the home > directory in this configuration, it may be useful to have them for > reference. > > http://tomcat.apache.org/migration.html#Before_upgrading_or_migrating > > http://tomcat.apache.org/migration-8.html#Upgrading_8.0.x > > 3) Many 3rd parties (Linux vendors) redistribute Tomcat with separate > home and base directories. > > Best regards, Konstantin Kolinko I think that the combined approach is useful in a number of scenarios. 1. Newbie-friendly Just unzip (untar, install) and go. With the installer I suppose you could have it query where CATALINA_BASE and CATALINA_HOME are to be placed, so the environment variables are constructed and placed in setenv.(bat/sh). If you use the archive rather than the installer, it's up to the user to figure this out. 2. IDE-friendly NetBeans works well with the combined approach. It even uses the standard manager-script role for deployment. Eclipse is not quite as nice, but again using the combined version makes integrating Tomcat with Eclipse as painless as it can be. IntelliJ seems to fit in between NetBeans and Eclipse in terms of Tomcat integration friendliness, and I don't know how it would be impacted by a default separation. Most developers are not very comfortable with administrative tasks (as most administrators are not very comfortable with developer tasks), so placing an additional barrier for developers would not be welcomed by many. 3. Differing install scenarios Finally, I can see a scenario somewhat like the following: a. explode a standard Tomcat distribution b. add a single web application - one per Tomcat c. package the result back up d. write a Chef cookbook for deploying this to 100s of machines For a large environment with clustered applications, this may be the way to go. It's facilitated (somewhat) by the combined approach. . . . just some ramblings /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUQBdSAAoJEEFGbsYNeTwtqLAIAJvDJxiS1eOHtV1XF1Dfezr1 u+Kom0QeROZ8XEKfcgYvS6Ig72UOFEsREdMvbUv6YfAGP9zZPagb4hvNfAsE4M3Q 9zzpgZovNXl94ZEDi9shcJqJg+oxFVvrzNHPDMryLIou1YmNJdOSbszeC4zgIge2 grYP4xqlMO8VqUTT1eNVbrtoDyEdjGxAJB9BkR+lYPw+tSqFq9u8C2EtRD2lBn7f EA97uE5qYLtoj69sI6ThRc26ox2ZtSiWv0ghwanJP8FhtnT7lLd47A+2GndFbxhx gSRa0z/AHM9x0qI71VyoJfKL41vZGaDZmuPDLU//BF429LfeYzEBOfVSIAmG9R0= =/suK -----END PGP SIGNATURE-----
