RE: Separation of CATALINA_HOME and CATALINA_BASE
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: 03 November 2014 20:51 To: Tomcat Users List Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE On 03/11/2014 19:38, vince.w...@thomsonreuters.com wrote: snip/ 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 Because you are trying to configure a listener that doesn't exist in the version of Tomcat you are trying to use. You can't take a config from one version of Tomcat, apply it to an earlier version and expect it to work. Mark Thank you. I wrongly assumed config would be compatible across different releases of Tomcat 8. 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 ? Yes. Mark - 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: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: 1) If you are a newbie administrator you are going to use easy-to-use-newbie-friendly configuration. It will get you started, it will get your application working, etc... Great starting point. 2) If you are developer (newbie or expert) and using IDE (Eclipse, Netbeans, IntelliJ) - you are going to use out-of-box tomcat configuration. Single Tomcat instance, no-split configuration. 3) If you are administrator that is upgrading Tomcat, you will just create a process to configure your instance with new Tomcat binaries and copy over the configuration file (most of the stuff is backwards compatible in server.xml within the point-version) + add any shared libraries to new tomcat/lib folder (JDBC drivers, etc...). Again, single-tomcat instance, no-split configuration necessary. Although, may people do like to split for easier upgrades and separation of concerns. 4) If you are administrator that is managing multi-instance environment, you can still get away with copying standard out-of-box Tomcat directory over and over again, for each instance separately. The hassle would be to do the upgrades on many instances. That's why we have CATALINA_HOME for shared stuff (binaries+libraries) and CATALINA_BASE for instance-specific configuration. And in this case you would know about the split directory setup option and would research how to do that effectively. My question is - why do you use CATALINA_BASE if you are using IDE (Netbeans)? If you are developer, there is no need to use split configuration. SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWPLHAAoJEBzwKT+lPKRYNmsP/3RR7xpKGttbs7iDwAzf29qu EwmQTJd063qcKiDABAkyFfwMy1IQL2/HMM30SL8XFGKhC0kFJZsr/r6kd/Y60cyN Q7+7uDNmvTtDvI4/3j2lTZ4e6gXo7UwTECxYcXinbM+eFnwZFH3xy/u1uC7vv4jV gcJ6TFZInqbArwJGDiCuKsaoPGZe1uqEGhCLJjSAz0Yx3gMZBkhi3wQHIGsZkknA Y9gVw0XAr3oAZHVZMf0bwP+ASH1RwwmRfn5dTgyxnQlAHiJCuA5AKdPtS0L/mkKj m0qk4MLx5+yWJw+Zll0qNkjgCVbZZ44qaDPwQiG2IFQjSj2dRU7a8PTtDjkPtklw SUZN1gqEdozuQPqivePN/QEZWqsnSGUtwRQvfr1cmpi4zcucgS7nyK+HE9ySX9/W H8y61BsTWRV/HHd/d+72/ZxQWH6qR0RKkRQDdwi116bdYb+gRp5B94l0EQ3MHMvB UemvCqvG6sxlB4gKdLjBbFYkn8YUjwRTSrQFbOmpGykW3hAbSnC1qHuwUPQ/ZM2T dqv1cnUn/BCGRUD+0xmiU/8UXim3DAxqaRknwfsWj5Lc5bOkdzWJKvg36fKHI/WD SB7Pcg9vyaV2NFFZh5kJU1xU4DhJ+ZWHqAOW+zzmB0wXqo+mlafkn3YidtMWRTYJ CKZvkdKcmf/6rIiIwRMJ =w+SD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Neven,
On 11/3/14 6:58 PM, Neven Cvetkovic wrote:
On Mon, Nov 3, 2014 at 6:42 PM, Neven Cvetkovic
neven.cvetko...@gmail.com wrote:
SLIGHTLY-OFFTOPIC:
Although, I would love to see out-of-box setup for additional
shared-lib folder, something other than TOMCAT/lib with Tomcat
default libraries. Essentially, I would love to separate my
customer shared libraries from Tomcat default libraries. I guess
- question would be where are CATALINA_HOME/lib JAR files being
loaded from? Can we add another directory to scan for libraries
to be loaded? Is that configurable?
I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
to now read:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar
Or
just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.
What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.
- -1
This is confusing and would be surprising if you hadn't intended to
use this. The shared loader was disabled by default because nobody
could figure out what the heck it was for and basically continually
broke their own configurations using it. So, now, everything goes into
either lib/ or the web application's WEB-INF/lib and everyone seems to
be happy. One can always re-enable the shared loader if you know it
exists, in which case you probably know what it's for and why you'd
use it. (Hint: use of the shared loader almost never makes any sense).
Default behaviour for
org.apache.catalina.startup.ClassLoaderFactory is to validate if
the file exists/isDirectory/isReadable? That might confuse
beginners with a Warning ...
I guess Tomcat philosophy is to keep it simple, and extensible - so
experts that need to customize things they can, and it is simple
and not confusing for beginners.
What are your thoughts?
I like the current default configuration but I'm willing to entertain
other ideas. I just don't like this one in particular (default to
split configuration).
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUWPO/AAoJEBzwKT+lPKRYhzwP/21gMhPUd7yVXzk/ImpkZMjr
chWiBFFXl8NA76onaHSvFEIAbwSYbpTjboCd2QdDu0qIFi/O4cyirnYhHRfPISGb
P+mHu0vg+9Ppze+uk5liQiULutEXdeqt97Sfom/I0j+GJZ2UxqvTGVIrwAa+63Op
7f8yg+wTXWQquz7vTkNwp/fGRBB5EB6ZJetffc0gPrsCG4L8muOobVhgd7wK9Yxf
wkWBSXVYTwgOIzlgdYBV2F92EiDMfPihOHQ+jgDHnxebOFc9jCppYcKa96c1LL36
7bTgdSvWNbxJXODCEBVUkoe2rbAr2u7/ZsRWiSOJlfPEBal9Rno/n3C/O6PAhA8J
xGB9ixtFyry9Z9V5XY+aUgI0+DKgSoddo2REtcuK0/X+mpyfUXB5A2GqNRaWxXSo
3+hHxfuJw8kLBjaWGswqgMhF0XBS07pNr87QDxldaROeg4Ty0apr6NRdkdSJ8eGE
+lvWIC+2dN7ufPo7tt3S0+cCDngvtpPMBdHtp7L1PplN9ilTBmxSYRcl/ZOMaE7J
hwSSsYFWRz/40EcTvkO6FCtiuWFW8490pqUuTvfz+ImO+rzSlAlJ2T0vq63Bbfjp
EwkVMlV1V421cDUI7JhyVsg1qw6lcsrY3wxPxXUpyGWMAUoQaScCcxGc1mN35D2/
5ufXCKK6w1sv89jfm5jg
=LSsh
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris The Tomcat zip file distribution could easily do this now. Add a CATALINA_BASE directory pre-configured with a read-me file that explains to users they can move this directory elsewhere, and update a property that points back to the CATALINA_HOME directory wherever they unzipped that. This would be an easy optional configuration to include for a split configuration.
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 11/3/2014 3:08 PM, Christopher Schultz wrote: Mark, On 11/3/14 5:46 PM, Mark Eggers wrote: One of the issues I did run into when using tcnative-1.dll is that I got the following error message: 12.0.0.1 is not a recognized command, and Tomcat failed to start. Moving tcnative-1.dll out of the bin directory fixed the problem. When I specified JRE_HOME in setenv.bat, that also fixed the problem and allowed me to use tcnative-1.dll. I suspect some brokenness in the way NetBeans is handling the JRE_HOME environment variable, since I do have that set system-wide. That's weird. It looks like someone a) mistyped 127.0.0.1 for localhost and b) a script isn't working properly. That should have been 127.0.0.1 Is this Netbeans-only, or does it happen with a stock Tomcat? It is NetBeans-only. Stock 8.0.14 starts fine using startup.bat from Windows Explorer. It's also odd that it has something to do with using tcnative at the same time. That was my quick and dirty thought since I did a grep (cygwin) on all of the files in CATALINA_HOME/bin, and that's the only file that mentioned 127.0.0.1. I moved tcnative-1.dll out of the bin directory and Tomcat started from within NetBeans. I then added a setenv.bat file to the directory which explicitly sets JRE_HOME (even though it's set as a global environment variable). NetBeans was then able to launch Tomcat even with tcnative-1.dll in the bin directory. I'll poke around if I have some time. I'll also see if this occurs on a Linux platform. -chris . . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUWPqxAAoJEEFGbsYNeTwtPooH/jpXYxwe5h97IsuI3kZ8Uprw OC2pTuJI8R95q1nATELEH44uMdWyu9YV6zyT0idkbZmdjU/VeFw7+QrtTop7or4J 4SH3ZTAFcvW4VqaQP3Z24kG1+8T9vpug1RsWnWabh8ioHz6qYKPEgvKhxa+fOopL gCbzEVObywOS/bRexilbZeJYUmQQOncEeVuqAQMpVqCW2yOf4DLJ+jtb7NVAalj+ H+YhVW8Adtip4DR8Kd/C0hIl5R/Gf8uEQjqlVh0SEPS8GwZFo9QJFhS6XD5Q44XK 0cMx/OHD8I6T/OVBAqND+Wf1KXUTfBnjQF9XeJvgs6MVCgMN2LKeutWxKXs5OpY= =Qhdj -END PGP SIGNATURE- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 11/4/14 10:46 AM, Leo Donahue wrote: On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris The Tomcat zip file distribution could easily do this now. Add a CATALINA_BASE directory pre-configured with a read-me file that explains to users they can move this directory elsewhere, and update a property that points back to the CATALINA_HOME directory wherever they unzipped that. This would be an easy optional configuration to include for a split configuration. It already does that, now: The CATALINA_BASE directory is preconfigured to be set to CATALINA_HOME, which is auto-detected by catalina.sh (.bat). CATALINA_BASE contains a readme file (RUNNING.txt) that explains how to change that default. I say that with all due snark, but it's really true: what you are talking about basically exists exactly as you describe. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWQB0AAoJEBzwKT+lPKRYm5oP/i1vfUFBWIsUmdOxFWIt44fZ ZL2Rco0+WFoUblC5JVjG+vfkv/ZFwUtJnbWVokm5ZZVtnD9LSwHvimeKMaq/wNSr 5yh+M/7cQXGmLEJV6tFf7eLLgHtEmH4WRgoWs/IJ827crxAjr2ae6w5HegWt8Yo1 r99g0x5ZFhlHBy8F1/xjykcTKZVYN3y7i47bcjgb0PDEC7rHB9RhLgveqwKPUU+x wDqKCHj6vLomgLL3adbU/kg5CV6UIgRwuD2Y3xuxHG3a4x3MoPfRhgmAzeetvm4i 9JXZGRbJhqs2mVNTBS3Bzwdj2rAF6LIROGwV/V7wqYDqgEIijssHUnY4GLaYbYOa kw+rpj7ZHfXfvmEFD5bo+7jc7v4Jp4SNQnES1bQJmhCytX/o/a0LjRuJ8H5WkTvA 2SobU1v9TMEtyu1esGjkcsibrCMqxfEmR3K8feKaRks1lCo2nlDKC5LsGrNykfW2 rI74FJyGCFP6sXOqckD6SGlyFXBrY4v6CI4sQc8iAsjPf8uWCyshfu7pWATC5C5g gr3ibDAQEICZWWlz3dlQuQtuf4sSU+XoLTWwyMls3fPMy/9+4BcvSPdcCmSKbGG2 +F9imb8uhrUOpLEhGo5pFBPx3JpjP0eBm1lU3WM3cWwFFBjBqt4GVBO9wFN9fjDg G+QWyQxZO/HdUUywyU6Z =zAEu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
On Tue, Nov 4, 2014 at 10:36 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 11/4/14 10:46 AM, Leo Donahue wrote: On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris The Tomcat zip file distribution could easily do this now. Add a CATALINA_BASE directory pre-configured with a read-me file that explains to users they can move this directory elsewhere, and update a property that points back to the CATALINA_HOME directory wherever they unzipped that. This would be an easy optional configuration to include for a split configuration. It already does that, now: The CATALINA_BASE directory is preconfigured to be set to CATALINA_HOME, which is auto-detected by catalina.sh (.bat). CATALINA_BASE contains a readme file (RUNNING.txt) that explains how to change that default. I say that with all due snark, but it's really true: what you are talking about basically exists exactly as you describe. - -chris You are correct (something muffled). If the Tomcat community wants to promote the concept of running multiple instances, then what about: A. A description of that functionality kind of starts on line 68 in RUNNING.txt ((3) Configure Environment Variables). In other words, it's buried. B. That description is aimed at using SCRIPTS not SERVICES to get it working. C. Under Advanced Configuration in RUNNING.txt all newbies really need to know is the In CATALINA_BASE part, because they will read the In CATALINA_HOME part and get confused. D. Are newbies after this kind of configuration for the thrill of being able to run multiple instances or for easier upgrades? My guess is most Tomcat users on Windows don't start their Tomcats with the scripts, a few do and those few are the ones who benefit from this ability, in their web app development. I haven't seen or heard of anyone who has a shared CATALINA_HOME sitting on a Windows file share where developers are free to create their own CATALINA_BASE, but I have only worked a few places in my life. And, I would wonder how coordinating the conflicting ports would be resolved as a group. leo
Re: Separation of CATALINA_HOME and CATALINA_BASE
Thanks Chris!
On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
to now read:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar
just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.
Yes, I missed that one :) that's what I had in mind.
What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.
- -1
This is confusing and would be surprising if you hadn't intended to
use this. The shared loader was disabled by default because nobody
could figure out what the heck it was for and basically continually
broke their own configurations using it. So, now, everything goes into
either lib/ or the web application's WEB-INF/lib and everyone seems to
be happy. One can always re-enable the shared loader if you know it
exists, in which case you probably know what it's for and why you'd
use it. (Hint: use of the shared loader almost never makes any sense).
Agreed, it might confusing. It's probably better idea to pack up your
libraries with your apps in WEB-INF/lib.
Why do shared loaders almost never make any sense? What kind of problems
did you have with shared.loader?
However, here's an (rare) example where that might be useful:
- one box with limited memory
- one tomcat instance hosting X (e.g. 10) applications
- all applications are using the same large shared libraries - e.g. 200MB
- you don't want to have a separate libraries for each application (your
PermGen space will grow significantly otherwise)
- it might make sense to move the shared libraries into shared folder (or
tomcat/lib)
Now, this architecture is probably not the greatest idea. I always strive
for the application/process isolation, i.e.
one-application-per-tomcat-instance - so I can have independent lifecycles
for my apps, but that requires more resources (memory,cpu) or even more
hardware.
I like the current default configuration but I'm willing to entertain
other ideas. I just don't like this one in particular (default to
split configuration).
So, I do agree - keeping it how it is - is probably the best idea. There is
always an option for people that would like to configure that further.
Thanks!
Neven
PS. Apologies for the off-topic diversion :)
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Neven,
On 11/4/14 1:05 PM, Neven Cvetkovic wrote:
Thanks Chris!
On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
to now read:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar
just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.
Yes, I missed that one :) that's what I had in mind.
What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.
- -1
This is confusing and would be surprising if you hadn't intended
to
use this. The shared loader was disabled by default because
nobody could figure out what the heck it was for and basically
continually broke their own configurations using it. So, now,
everything goes into either lib/ or the web application's
WEB-INF/lib and everyone seems to be happy. One can always
re-enable the shared loader if you know it exists, in which case
you probably know what it's for and why you'd use it. (Hint: use
of the shared loader almost never makes any sense).
Agreed, it might confusing. It's probably better idea to pack up
your libraries with your apps in WEB-INF/lib.
Why do shared loaders almost never make any sense? What kind of
problems did you have with shared.loader?
The only use case I've seen in the past for using a shared loader is
when people get paranoid about disk space and want to put all their
libraries under shared so they don't have extra copies of e.g.
Struts, Spring, etc. when all of their web applications depend on the
same set of prerequisites.
Of course, then we get endless questions about why their app A doesn't
work anymore because they have Spring 3.5 installed in their shared
loaded and Spring 4.0 installed in their web application and
everything goes all to hell. Basically, they outsmarted themselves and
the code is punishing them for it.
Tomcat then gets blamed for an inflexible configuration system when
Tomcat's flexibility is what allowed them to set up this foolish
configuration in the first place.
I think most of us are better off without the shared loader.
However, here's an (rare) example where that might be useful: - one
box with limited memory - one tomcat instance hosting X (e.g. 10)
applications - all applications are using the same large shared
libraries - e.g. 200MB - you don't want to have a separate
libraries for each application (your PermGen space will grow
significantly otherwise) - it might make sense to move the shared
libraries into shared folder (or tomcat/lib)
Agreed, but with the caveats indicated above.
Now, this architecture is probably not the greatest idea. I always
strive for the application/process isolation, i.e.
one-application-per-tomcat-instance - so I can have independent
lifecycles for my apps, but that requires more resources
(memory,cpu) or even more hardware.
Exactly: packaging your application as a self-contained unit means
fewer surprises all around.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUWRumAAoJEBzwKT+lPKRY/GYP+wc5EaHui1jmx1JoAtps9Z8W
F51OL86n43SpQYN6kpkr2nsew8vpApPX6MXrC8C2XY7AIGzXdclxTmt6Wcf+Rllj
bVrGFDe+tO7NKS44M4z4ZRRAlg7xVc0i/E9rHMdkxSPatDbsBM6t08R8x5se/l8/
C/iscgqVGXTmvA52c2xBLJmXiwXCDSb24HDji2kUzNo7irlaX4QxpvAWNUoCF566
4/tv4xvOrfDbo4INfQ+QtJbEMdFJNlJ2GtPYBF9jmsO9DGMUJ5PIkd7E7vbDr0Ac
fuKGFEiYpOIKNd9PZ99z/bV+Wo8DIpw5kzAUQArQzXqxq0BvNcErVnY5JM4mAyaE
rt4m8TRPCxgwQIuNk9dO7jG25PhDbzw/RWnoiGbbWrV+uBLwpUMU3htMgXuhuAO1
lHa8GaiRFRFBCBeI1yG8PzZEks9DoB5MCXS1tzBIN855bSL4rgYwAMSeTKTfaxzK
DCUJHcKQ71Bcq1neMVsVv3SAPCo4gsi4JPquhiJLo3WIqSV/MVX9rshRQ83VnrAO
nxobgJFsnXXe8VouPLlR6NyR8w9H6EwoTUM6ARayAUtfSqBaKBym/6Cylc71QnrG
HCCxuey8GP7dt8nnSqTkfthmojgfPZl6cAQ1RV2FRcnHcLMtJgPjGfTxuiXBtg1m
FCGaUtFhBsdmsQpdYLN4
=dNsl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Separation of CATALINA_HOME and CATALINA_BASE
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
Re: Separation of CATALINA_HOME and CATALINA_BASE
Vince, On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com wrote: 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. Why is that? I would argue current setup is very simple and newbie-friendly. Most newbies are going to have a single-instance tomcat running, even developers in their IDEs (Eclipse, NetBeans, IntelliJ, etc...) would probably start with a single Tomcat instance. You want your CATALINA_HOME = CATALINA_BASE in the newbie situation. Actually you don't even want to advertise the difference to the newbies. You probably shouldn't even configure CATALINA_HOME/CATALINA_BASE environment variables, but let the scripts infer from where you are running them. Now, once one graduates pass the newbie-friendly - one can start looking when CATALINA_HOME != CATALINA_BASE is useful. Here are some ideas, why you would maybe want to separate out CATALINA_HOME and CATALINA_BASE: a) when you want to make your Tomcat upgrades easier over time, so you just upgrade your CATALINA_HOME each time and you keep your existing CATALINA_BASE (instance configuration) directory. b) multi-instance environment, when you have multiple Tomcat instances running on the same machine, and you are sick-and-tired of copying entire tomcat directory for each instance and do the upgrades for each instance individually Other than that, I don't see another reason to have CATALINA_HOME and CATALINA_BASE be any different. 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. Exactly my point earlier Vince. You ignore setting up CATALINA_HOME/CATALINA_BASE, you let the scripts infer that from where it is being started. And then you just configure your datasource either at the GlobalNamingResources level (e.g at conf/server.xml) or at the Context level (e.g. at conf/Catalina/localhost/myapp.xml). 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 ? If you are running Tomcat instance in IDE, why do you bother separating out CATALINA_BASE and CATALINA_HOME? Default unzip and play setup work nicely in Eclipse and IntelliJ. I have not played with NetBeans as much, but I am sure it is easy out-of-box setup. Hope that helps! Cheers! Neven
Re: Separation of CATALINA_HOME and CATALINA_BASE
On 03/11/2014 19:38, vince.w...@thomsonreuters.com wrote: snip/ 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 Because you are trying to configure a listener that doesn't exist in the version of Tomcat you are trying to use. You can't take a config from one version of Tomcat, apply it to an earlier version and expect it to work. 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 ? Yes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Vince,
On 11/3/14 2:38 PM, vince.w...@thomsonreuters.com wrote:
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.
Here's my (simplified) prepare-local-tomcat target from our ant build
scripts. It takes a CATALINA_HOME and builds a CATALINA_BASE from it
and our other revision-controlled configuration files.
app.tomcat-home is CATALINA_HOME
app.home.dir is CATALINA_BASE
app.foo.dir should be obvious from the name/usage
conf.dir is our revision-controlled stuff
target name=prepare-local-tomcat
mkdir dir=${app.home.dir} /
mkdir dir=${app.conf.dir} /
mkdir dir=${app.webapps.dir} /
mkdir dir=${app.log.dir} /
mkdir dir=${app.temp.dir} /
!-- Prepare and install Tomcat configuration files for the
application --
!-- Copy the stock web.xml from the tomcat installation --
copy
file=${app.tomcat-home}/conf/web.xml
tofile=${app.conf.dir}/web.xml
/
!--
Copy tomcat-server.xml to server.xml in the local Tomcat conf dir.
Use filters to substitute-in the values for the connector and
shutdown
ports.
--
copy
file=${conf.dir}/${app.release-type}/tomcat-server-${app.tomcat-version}.xml
tofile=${app.conf.dir}/server.xml
filtering=yes
/
/target
Basically, all a CATALINA_BASE needs is conf/server.xml, conf/web.xml,
a log directory, and a work directory. I haven't bothered checking,
but you might not even need conf/web.xml... Tomcat might automatically
use the CATALINA_HOME/conf/web.xml if there isn't one in
CATALINA_BASE/conf/web.xml.
We still use webapps though we could deploy anywhere we wanted to.
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
It looks like you are trying to use the server.xml file from Tomcat
8.0.14 on Tomcat 8.0.9. The VersionLoggerListener class was introduced
relatively recently.
If you want to adapt server.xml from one version of Tomcat to another,
you should be careful. You have inadvertently downgraded your Tomcat
instance and lost functionality.
So, basically, you have damaged your Tomcat installation and want to
know why it doesn't work. Well, you broke it, so it doesn't work.
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 ?
Yes. Tomcat's CLASSPATH includes only things within CATALINA_HOME/bin
and CATALINA_BASE/bin (in that order). Everything else (like the stuff
in CATALINA_HOME/lib and CATALINA_BASE/lib) gets added to a
ClassLoader that is used after the server bootstraps itself.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUV+6wAAoJEBzwKT+lPKRYFrkP/iLMieBMpVuAW2FQohnJ+slQ
wgCN3kjuK3JCip1zVHZzUWvS2x0hDs+XWrNDLGtk36NDH9++k5z94GQjVukn5vFa
yaRKADjmNuLSzEj4dPbj7mFz3Vj0lmkxLLvuslyMQZe9WKqE7qeo8q0aw5v2M1uc
h5jZuCS54HdTbioXx2++YeQEaT1jqw6Iuk4acWkaKWS+8B/epXqMHh0yNBkI50un
EY+YwOJ1MQ5WbDEFw/nRUkbVMMQHpY6uWPxkqu5Te+JaUPRlnHD6qzhQCCjDJ92y
zGnGLkE5koo+cVCpVKosznJCw/ZCnf4Pub7NqtPysXe7smVBrCzMvQ1+IjDw4rUi
KK/e+9DtCLhq3HVcY4Nc03xycqADGMVeyASJgdf+ONRS7QhGFh7JJgSw+Xwfk9tM
Wu0VB3W2iC87F8Iag6prowFav7AYt4MmYuY224emaOVhmnOgHHGYi+DDAABw6dK9
KCPnFg6IOJaOUuNpCY6UHebVyVibglCsNZTrqRWX0o7vKYnDinEtL8YqwYrgfHZc
9E5RUJJ3kvz+Ptx2mkopS+JLx9Yll1bkOjPjC2k0kesc2gVknlRXzkjYO2I+VxGR
b64UnEklwLMkDOBpF2kz/K57sYbPxxR5oJfi3CAGs0ixENyamLWXv3i9d8CXcf+Z
RE: Separation of CATALINA_HOME and CATALINA_BASE
Neven Even Tomcat newbies have to do real work that will find its way to a real server. Either of the benefits you described as a) and b) mean CATALINA_HOME and CATALINA_BASE need to be separate on a real server. I would rather get it straight from the outset rather than mess about with a configuration that is going nowhere. NetBeans separates out CATALINA_HOME and CATALINA_BASE, either automatically making its own decisions about the content of CATALINA_BASE or manually by allowing you to specify your own hand crafted directory. I just made the switch from letting NetBeans populate CATALINA_BASE, to doing it myself. Naturally I want to avoid having the same files appear in both directories so I went for minimal content. How much easier it would be if the Tomcat distribution had the correct separation build in. Vince -Original Message- From: Neven Cvetkovic [mailto:neven.cvetko...@gmail.com] Sent: 03 November 2014 20:22 To: Tomcat Users List Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE Vince, On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com wrote: 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. Why is that? I would argue current setup is very simple and newbie-friendly. Most newbies are going to have a single-instance tomcat running, even developers in their IDEs (Eclipse, NetBeans, IntelliJ, etc...) would probably start with a single Tomcat instance. You want your CATALINA_HOME = CATALINA_BASE in the newbie situation. Actually you don't even want to advertise the difference to the newbies. You probably shouldn't even configure CATALINA_HOME/CATALINA_BASE environment variables, but let the scripts infer from where you are running them. Now, once one graduates pass the newbie-friendly - one can start looking when CATALINA_HOME != CATALINA_BASE is useful. Here are some ideas, why you would maybe want to separate out CATALINA_HOME and CATALINA_BASE: a) when you want to make your Tomcat upgrades easier over time, so you just upgrade your CATALINA_HOME each time and you keep your existing CATALINA_BASE (instance configuration) directory. b) multi-instance environment, when you have multiple Tomcat instances running on the same machine, and you are sick-and-tired of copying entire tomcat directory for each instance and do the upgrades for each instance individually Other than that, I don't see another reason to have CATALINA_HOME and CATALINA_BASE be any different. 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. Exactly my point earlier Vince. You ignore setting up CATALINA_HOME/CATALINA_BASE, you let the scripts infer that from where it is being started. And then you just configure your datasource either at the GlobalNamingResources level (e.g at conf/server.xml) or at the Context level (e.g. at conf/Catalina/localhost/myapp.xml). 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 ? If you are running Tomcat instance in IDE, why do you bother separating out CATALINA_BASE and CATALINA_HOME? Default unzip and play setup work nicely in Eclipse and IntelliJ. I have not played with NetBeans as much, but I am sure it is easy out-of-box setup. Hope that helps! Cheers! Neven
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vince, On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote: Even Tomcat newbies have to do real work that will find its way to a real server. Either of the benefits you described as a) and b) mean CATALINA_HOME and CATALINA_BASE need to be separate on a real server. I would rather get it straight from the outset rather than mess about with a configuration that is going nowhere. Separating a unified Tomcat deployment into CATALINA_HOME and CATALINA_BASE is pretty trivial. Your configuration isn't going nowhere. Do you know what's worse than a simple configuration to start that can grow into a complex one? One that is so complex you can't even get started. Have you ever configured Weblogic? There is (or was, back in circa 2001 when I had the misfortune of working on that platform) no such thing as unzip and run bin/startup.sh to launch the server. No, you basically had to go and get trained (at a high cost, by corporate trainers, of course) to do anything at all with the darned thing. If you want to talk about a configuration that is going nowhere, anything that is automatically done by Eclipse, NetBeans, etc. is not going anywhere. NetBeans separates out CATALINA_HOME and CATALINA_BASE, either automatically making its own decisions about the content of CATALINA_BASE or manually by allowing you to specify your own hand crafted directory. I just made the switch from letting NetBeans populate CATALINA_BASE, to doing it myself. Naturally I want to avoid having the same files appear in both directories so I went for minimal content. How much easier it would be if the Tomcat distribution had the correct separation build in. It would be harder for newbies and no real benefit to experts. Let me show you the difference in complexity between deploying Tomcat with a unified versus split configuration: Unified - --- $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ tomcat-x.y.z/bin/startup.sh Woot! Separated - - $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml my-tomcat-base/conf (the above step may not actually be necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export CATALINA_BASE=`pwd`/my-tomcat-base $ $CATALINA_HOME/bin/startup.sh Done. So, that's not all that complicated when you think about it, but to ask someone who knows nothing about a command-line, working effectively in an operating system, etc. and only knows about programming in Java -- maybe only servlet programming in Java -- to configure the server in the split case is confusing as all hell. Anyone downloading a ZIP or tar archive containing a Tomcat installation would be confused if the archive contained not one but two top-level directories. Also, it would overwrite your split-configuration if you unpacked that archive in the same directory as when you first started. An installer program would have to explain what in the world the split configuration was. Have you ever tried to tell someone how to set up their email? POP versus IMAP? Most users have absolutely no idea what that is, and mail programs give no clue as to which one to choose. The same would be true of CATALINA_HOME versus CATALINA_BASE. (Besides, I truly doubt that any expert system administrators are using the Tomcat Windows Installer to install/upgrade their systems. Maybe I'm wrong, but then again I can't imagine running a Windows server in production. I value my sleep and prefer to build new things instead of holding together configurations with chewing gum and duct tape. Oh, and rebooting all the time.) Anyhow, we can debate this all you want, but I will be -0 or even -1 to a default split-configuration of Tomcat unless someone has a really good idea for how to make it make sense to anyone on their first-touch. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUV/STAAoJEBzwKT+lPKRYwq0QAJis//26ab34xcdAbs1Ths8I 0D4XWjh8cNv+QqvexftR8atf+2mN4NCukeHe95CF7AT0GVF0hd/z6irzRp32OXVd gg8nQkn4u+OjzHC2aCDSHGTDvg2/rkf1RdKqSD84pooB56d6hysMszCdHVZNFKHY 6SCOIFcwiVE/iiaLmV39uyT5tgcMQyAVZ0g9xym3tJHT8pXiFQ4pKZQKxnl4PBhx ob+l1ksb4gaekFV/WIQEr9HLS73FLcHr9rk0VtsM+4HiE8t2XacYKXveewShWXUX +kaFD0Udb5VCqlqMRKKZKw2a9kOh2XYGI7C+itYBHVRUXtW//jtwd2G6fje+5Siz phSB+aq6kHK2iEF4ZxGQ2asqCFrCCBWPfMtrrWScKHrPVYj7suAcLpfk2oaFksGD BER8LT8WRi35L9VbemNMfFPCSFFEyP2Ej7Xa09ZdS4jqd1O8m8ZsWxHDW5JbYL2s bcffVeHhZvglyKHfcciCYzSDdFprsI0qglFgVtRy/E35Gn6FkyS23npHl1zeehhy J/2a/4STTexpMZtC2e1E5nDb+/m3qAn9SkBYW5IxeU9jrYBx1aQeZqt2TxCj4Kt9
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vince, On 11/3/2014 1:12 PM, vince.w...@thomsonreuters.com wrote: Neven Even Tomcat newbies have to do real work that will find its way to a real server. Either of the benefits you described as a) and b) mean CATALINA_HOME and CATALINA_BASE need to be separate on a real server. I would rather get it straight from the outset rather than mess about with a configuration that is going nowhere. NetBeans separates out CATALINA_HOME and CATALINA_BASE, either automatically making its own decisions about the content of CATALINA_BASE or manually by allowing you to specify your own hand crafted directory. Actually, at least in recent versions of NetBeans this is not the default case. The default case is to use CATALINA_HOME and let NetBeans completely control the Tomcat instance. This is the way I normally run NetBeans on my development systems. I rarely use CATALINA_BASE in development, since I just add all of the extra jars to $CATALINA_HOME/lib. I just made the switch from letting NetBeans populate CATALINA_BASE, to doing it myself. Naturally I want to avoid having the same files appear in both directories so I went for minimal content. This is only true if you select the check box in the server creation wizard that is labeled Use Private Configuration Folder (Catalina Base). In short, NetBeans follows the instructions set down in RUNNING.txt. This is one of the reasons I like NetBeans over other development environments. How much easier it would be if the Tomcat distribution had the correct separation build in. IMHO, I think the way Tomcat currently does it is optimal. Keep it simple for those people who want to just unpack and go, while making it relatively easy for those people who want more flexibility. Vince For a development environment, I just typically unpack Tomcat somewhere, edit tomcat-users.xml, point NetBeans to it, and go. Typically, a development environment can contain all of the extra JARs required for development. This of course means a slightly slower Tomcat start up. If the start up times are onerous, then you can go ahead and use CATALINA_HOME and CATALINA_BASE in NetBeans quite easily. It's the same as setting things up in production, with the exception that NetBeans populates CATALINA_HOME and CATALINA_BASE based on the values you entered in the wizard (no environment variables to set). 1. Set up an unaltered Tomcat in one directory 2. Create a duplicate directory structure somewhere else - to whit: CATALINA_BASE-+ +-bin +-conf +-lib +-logs +-temp +-webapps +-work 3. Copy tomcat-juli.jar from CATALINA_HOME/bin to CATALINA_BASE/bin 4. Copy all of the stuff from CATALINA_HOME/conf to CATALINA_BASE/conf 5. Edit CATALINA_BASE/conf/server.xml a. change the Server port b. change HTTP/1.1 connector port c. change the HTTPS connector port or comment it out d. change the AJP connector port or comment it out 6. Edit tomcat-users.xml 7. Copy over the manager application a. Copy over the application from CATALINA_HOME/webapps - OR - b. Create a manager.xml in CATALINA_BASE/conf/Catalina/[hostname] ?xml version=1.0 encoding=UTF-8? Context docBase=location of manager application in CATALINA_HOME antiResourceLocking=false privileged=true useHttpOnly=true/ c. useHttpOnly=true is default for 7.0.x d. [hostname] is typically localhost for single Host server.xml To modify what extra JARs are needed for this CATALINA_BASE, just add them to CATALINA_BASE/lib. This way your pristine Tomcat remains pristine. This works for both NetBeans-controlled Tomcats and Tomcats not running under an IDE. Please note that the default mechanism used by Eclipse is quite different. . . . just my two cents. /mde/ -Original Message- From: Neven Cvetkovic [mailto:neven.cvetko...@gmail.com] Sent: 03 November 2014 20:22 To: Tomcat Users List Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE Vince, On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com wrote: 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. Why is that? I would argue current setup is very simple and newbie-friendly. Most newbies are going to have a single-instance tomcat running, even developers in their IDEs (Eclipse, NetBeans, IntelliJ, etc...) would probably start with a single Tomcat instance. You want your CATALINA_HOME = CATALINA_BASE in the newbie situation. Actually you don't even want to advertise the difference to the newbies. You probably shouldn't even configure CATALINA_HOME/CATALINA_BASE environment variables, but let the scripts infer from where you are running them. Now, once one graduates
Re: Separation of CATALINA_HOME and CATALINA_BASE
On Mon, Nov 3, 2014 at 3:33 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vince, On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote: How much easier it would be if the Tomcat distribution had the correct separation build in. It would be harder for newbies and no real benefit to experts. Let me show you the difference in complexity between deploying Tomcat with a unified versus split configuration: Unified - --- $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ tomcat-x.y.z/bin/startup.sh You can do that in linux. not so well in windows. scripts work differently. you log out of the windows session, and the script stops, hence why every windows user wants to install Tomcat as a service, whichever way they do that. Separated - - $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml my-tomcat-base/conf (the above step may not actually be necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export CATALINA_BASE=`pwd`/my-tomcat-base $ $CATALINA_HOME/bin/startup.sh Done. So, that's not all that complicated when you think about it, but to ask someone who knows nothing about a command-line, working effectively in an operating system, etc. and only knows about programming in Java -- maybe only servlet programming in Java -- to configure the server in the split case is confusing as all hell. Anyone downloading a ZIP or tar archive containing a Tomcat installation would be confused if the archive contained not one but two top-level directories. Also, it would overwrite your split-configuration if you unpacked that archive in the same directory as when you first started. An installer program would have to explain what in the world the split configuration was. Have you ever tried to tell someone how to set up their email? POP versus IMAP? Most users have absolutely no idea what that is, and mail programs give no clue as to which one to choose. The same would be true of CATALINA_HOME versus CATALINA_BASE. Everything has some degree of learning. New people are trying to learn two things at once, how something works as well as the why do it this way conventions that experienced users have implemented. New users don't understand the convention and want to learn it the hard way first before they can appreciate or even understand the convention. (Besides, I truly doubt that any expert system administrators are using the Tomcat Windows Installer to install/upgrade their systems. Maybe I'm wrong, You had qualify that with 'expert'... now I have nothing more to add. but then again I can't imagine running a Windows server in production. This too shall pass... I value my sleep and prefer to build new things instead of holding together configurations with chewing gum and duct tape. Oh, and rebooting all the time.) Anyhow, we can debate this all you want, but I will be -0 or even -1 to a default split-configuration of Tomcat unless someone has a really good idea for how to make it make sense to anyone on their first-touch. - -chris I would rather just point (windows) people to an example of a split configuration or any other configuration and let them implement it if they choose to do so, instead of getting Tomcat pre-configured. Part of the draw to Tomcat is that you have flexibility with how you choose to run it (script, service, windows installer, etc)
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 11/3/2014 1:33 PM, Christopher Schultz wrote: Vince, On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote: Even Tomcat newbies have to do real work that will find its way to a real server. Either of the benefits you described as a) and b) mean CATALINA_HOME and CATALINA_BASE need to be separate on a real server. I would rather get it straight from the outset rather than mess about with a configuration that is going nowhere. Separating a unified Tomcat deployment into CATALINA_HOME and CATALINA_BASE is pretty trivial. Your configuration isn't going nowhere. Do you know what's worse than a simple configuration to start that can grow into a complex one? One that is so complex you can't even get started. Have you ever configured Weblogic? There is (or was, back in circa 2001 when I had the misfortune of working on that platform) no such thing as unzip and run bin/startup.sh to launch the server. No, you basically had to go and get trained (at a high cost, by corporate trainers, of course) to do anything at all with the darned thing. Other application servers are equally unpleasant in my experience. If you want to talk about a configuration that is going nowhere, anything that is automatically done by Eclipse, NetBeans, etc. is not going anywhere. By default, NetBeans does absolutely nothing to change the Tomcat configuration. Even if you decide to use a separate CATALINA_HOME and CATALINA_BASE, NetBeans follows the model detailed in RUNNING.txt. NetBeans separates out CATALINA_HOME and CATALINA_BASE, either automatically making its own decisions about the content of CATALINA_BASE or manually by allowing you to specify your own hand crafted directory. I just made the switch from letting NetBeans populate CATALINA_BASE, to doing it myself. Naturally I want to avoid having the same files appear in both directories so I went for minimal content. How much easier it would be if the Tomcat distribution had the correct separation build in. It would be harder for newbies and no real benefit to experts. Let me show you the difference in complexity between deploying Tomcat with a unified versus split configuration: Unified --- $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ tomcat-x.y.z/bin/startup.sh Woot! Separated - $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml my-tomcat-base/conf (the above step may not actually be necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export CATALINA_BASE=`pwd`/my-tomcat-base $ $CATALINA_HOME/bin/startup.sh Done. This is not so bad for a person used to the command line, but getting a developer on any platform to do this is going to be a challenge. If that developer is only familiar with Windows or the Macintosh at a user level, you've placed an almost insurmountable burden in getting Tomcat to run. So, that's not all that complicated when you think about it, but to ask someone who knows nothing about a command-line, working effectively in an operating system, etc. and only knows about programming in Java -- maybe only servlet programming in Java -- to configure the server in the split case is confusing as all hell. +1 Anyone downloading a ZIP or tar archive containing a Tomcat installation would be confused if the archive contained not one but two top-level directories. Also, it would overwrite your split-configuration if you unpacked that archive in the same directory as when you first started. An installer program would have to explain what in the world the split configuration was. Have you ever tried to tell someone how to set up their email? POP versus IMAP? Most users have absolutely no idea what that is, and mail programs give no clue as to which one to choose. The same would be true of CATALINA_HOME versus CATALINA_BASE. (Besides, I truly doubt that any expert system administrators are using the Tomcat Windows Installer to install/upgrade their systems. Maybe I'm wrong, but then again I can't imagine running a Windows server in production. I value my sleep and prefer to build new things instead of holding together configurations with chewing gum and duct tape. Oh, and rebooting all the time.) I (sadly) run a few Windows servers in production. I've not tried CATALINA_HOME / CATALINA_BASE in conjunction with the service install, since those systems are quite static. However, even updating Java on those systems is a bit of a pain. Rebooting is also not nice for reliability /
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 11/3/14 5:05 PM, Leo Donahue wrote: On Mon, Nov 3, 2014 at 3:33 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vince, On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote: How much easier it would be if the Tomcat distribution had the correct separation build in. It would be harder for newbies and no real benefit to experts. Let me show you the difference in complexity between deploying Tomcat with a unified versus split configuration: Unified - --- $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ tomcat-x.y.z/bin/startup.sh You can do that in linux. not so well in windows. scripts work differently. you log out of the windows session, and the script stops, hence why every windows user wants to install Tomcat as a service, whichever way they do that. Okay: C:\whatever wget http://host/path/to/tomcat-x.y.z.zip C:\whatever unzip http://host/path/to/tomcat-x.y.z.zip (or however you unzip from the CLI in Windows.. I haven't been able to figure that out, but it's clearer than giving mouse-click directions) C:\whatever SET CATALINA_HOME=C:\whatever\apache-tomcat-x.y.z C:\whatever SET CATALINA_BASE=C:\whatever\apache-tomcat-x.y.z C:\whatever %CATALINA_HOME%\bin\service.bat install my-great-webapp C:\whatever service start my-great-webapp Separated - - $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml my-tomcat-base/conf (the above step may not actually be necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export CATALINA_BASE=`pwd`/my-tomcat-base $ $CATALINA_HOME/bin/startup.sh For Windowers: C:\whatever wget http://host/path/to/tomcat-x.y.z.zip C:\whatever unzip http://host/path/to/tomcat-x.y.z.zip (or however you unzip from the CLI in Windows.. I haven't been able to figure that out, but it's clearer than giving mouse-click directions) C:\whatever mkdir my-tomcat-base/conf C:\whatever mkdir my-tomcat-base/log C:\whatever mkdir my-tomcat-base/work C:\whatever mkdir my-tomcat-base/temp C:\whatever mkdir my-tomcat-base/webapps C:\whatever SET CATALINA_HOME=C:\whatever\apache-tomcat-x.y.z C:\whatever SET CATALINA_BASE=C:\whatever\my-tomcat-base C:\whatever %CATALINA_HOME%\bin\service.bat install my-great-webapp C:\whatever service start my-great-webapp (All this from memory... apologies if those exact commands don't work.) Done. So, that's not all that complicated when you think about it, but to ask someone who knows nothing about a command-line, working effectively in an operating system, etc. and only knows about programming in Java -- maybe only servlet programming in Java -- to configure the server in the split case is confusing as all hell. Anyone downloading a ZIP or tar archive containing a Tomcat installation would be confused if the archive contained not one but two top-level directories. Also, it would overwrite your split-configuration if you unpacked that archive in the same directory as when you first started. An installer program would have to explain what in the world the split configuration was. Have you ever tried to tell someone how to set up their email? POP versus IMAP? Most users have absolutely no idea what that is, and mail programs give no clue as to which one to choose. The same would be true of CATALINA_HOME versus CATALINA_BASE. Everything has some degree of learning. New people are trying to learn two things at once, how something works as well as the why do it this way conventions that experienced users have implemented. New users don't understand the convention and want to learn it the hard way first before they can appreciate or even understand the convention. Agreed. The point I'm trying to make is that experts are experts because they have learned. Peeling-back the covers of Tomcat reveals those expert features like a split configuration. Being forced to use a split-configuration because it's what experts do is one sure way to generate a lot of noise on this mailing list. (Besides, I truly doubt that any expert system administrators are using the Tomcat Windows Installer to install/upgrade their systems. Maybe I'm wrong, You had qualify that with 'expert'... now I have nothing more to add. but then again I can't imagine running a Windows server in production. This too shall pass... I value my sleep and prefer to build new things instead of holding together
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neven and Vince, It's dead-simple to run under NetBeans. Just unzip and go - use the defaults. On 11/3/2014 12:21 PM, Neven Cvetkovic wrote: Vince, On Mon, Nov 3, 2014 at 2:38 PM, vince.w...@thomsonreuters.com wrote: 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. Why is that? I would argue current setup is very simple and newbie-friendly. Most newbies are going to have a single-instance tomcat running, even developers in their IDEs (Eclipse, NetBeans, IntelliJ, etc...) would probably start with a single Tomcat instance. You want your CATALINA_HOME = CATALINA_BASE in the newbie situation. Actually you don't even want to advertise the difference to the newbies. You probably shouldn't even configure CATALINA_HOME/CATALINA_BASE environment variables, but let the scripts infer from where you are running them. Now, once one graduates pass the newbie-friendly - one can start looking when CATALINA_HOME != CATALINA_BASE is useful. Here are some ideas, why you would maybe want to separate out CATALINA_HOME and CATALINA_BASE: a) when you want to make your Tomcat upgrades easier over time, so you just upgrade your CATALINA_HOME each time and you keep your existing CATALINA_BASE (instance configuration) directory. b) multi-instance environment, when you have multiple Tomcat instances running on the same machine, and you are sick-and-tired of copying entire tomcat directory for each instance and do the upgrades for each instance individually Other than that, I don't see another reason to have CATALINA_HOME and CATALINA_BASE be any different. 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. Exactly my point earlier Vince. You ignore setting up CATALINA_HOME/CATALINA_BASE, you let the scripts infer that from where it is being started. And then you just configure your datasource either at the GlobalNamingResources level (e.g at conf/server.xml) or at the Context level (e.g. at conf/Catalina/localhost/myapp.xml). 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 And the above is broken. You've checked the box marked Use Private Configuration Folder (Catalina Base) without setting that folder up properly. I'm surprised that NetBeans even allowed you to complete that configuration if it didn't find the requisite folder structure / JARs / configuration files in C:\tomcat8catalina_base. 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 ? Yes. There is no need to have a long CLASSPATH with Tomcat. If you are running Tomcat instance in IDE, why do you bother separating out CATALINA_BASE and CATALINA_HOME? Default unzip and play setup work nicely in Eclipse and IntelliJ. I have not played with NetBeans as much, but I am sure it is easy out-of-box setup. Hope that helps! Cheers! Neven I just did the following without any trouble under NetBeans 8.0.1. 1. Downloaded 8.0.14 (I know 8.0.15 is about out) Windows 64 bit zip 2. Unzipped it 3. Backed up tomcat-users.xml 4. Copied over my tomcat-users.xml from 7.0.56 5. Copied over my setenv.bat from 7.0.56 (sets up JMX, etc) 6. Configured the server in NetBeans a. used defaults b. added the user with manager-script role 7. Started it One of the issues I did run into when using tcnative-1.dll is that I got the following error message: 12.0.0.1 is not a recognized
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 11/3/14 5:16 PM, Mark Eggers wrote: Chris, On 11/3/2014 1:33 PM, Christopher Schultz wrote: Vince, On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote: Even Tomcat newbies have to do real work that will find its way to a real server. Either of the benefits you described as a) and b) mean CATALINA_HOME and CATALINA_BASE need to be separate on a real server. I would rather get it straight from the outset rather than mess about with a configuration that is going nowhere. Separating a unified Tomcat deployment into CATALINA_HOME and CATALINA_BASE is pretty trivial. Your configuration isn't going nowhere. Do you know what's worse than a simple configuration to start that can grow into a complex one? One that is so complex you can't even get started. Have you ever configured Weblogic? There is (or was, back in circa 2001 when I had the misfortune of working on that platform) no such thing as unzip and run bin/startup.sh to launch the server. No, you basically had to go and get trained (at a high cost, by corporate trainers, of course) to do anything at all with the darned thing. Other application servers are equally unpleasant in my experience. If you want to talk about a configuration that is going nowhere, anything that is automatically done by Eclipse, NetBeans, etc. is not going anywhere. By default, NetBeans does absolutely nothing to change the Tomcat configuration. Even if you decide to use a separate CATALINA_HOME and CATALINA_BASE, NetBeans follows the model detailed in RUNNING.txt. NetBeans separates out CATALINA_HOME and CATALINA_BASE, either automatically making its own decisions about the content of CATALINA_BASE or manually by allowing you to specify your own hand crafted directory. I just made the switch from letting NetBeans populate CATALINA_BASE, to doing it myself. Naturally I want to avoid having the same files appear in both directories so I went for minimal content. How much easier it would be if the Tomcat distribution had the correct separation build in. It would be harder for newbies and no real benefit to experts. Let me show you the difference in complexity between deploying Tomcat with a unified versus split configuration: Unified --- $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ tomcat-x.y.z/bin/startup.sh Woot! Separated - $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml my-tomcat-base/conf (the above step may not actually be necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export CATALINA_BASE=`pwd`/my-tomcat-base $ $CATALINA_HOME/bin/startup.sh Done. This is not so bad for a person used to the command line, but getting a developer on any platform to do this is going to be a challenge. I presented those examples in CLI terms because they are brief, concise, and correct. The Nullsoft Installer basically does that same stuff but with safety gear surrounding it. If that developer is only familiar with Windows or the Macintosh at a user level, you've placed an almost insurmountable burden in getting Tomcat to run. While a Mac installer might be nice, it's really not hard to unzip and then bin/startup.sh on Mac. I'd argue that about Windows, but I recently did some consulting with a company full of Windows administrators and when I dropped to the command-line to get some real work done (my words to them), they all got a panicked expression on their faces. I guess without a point-and-click interface, some folks are just lost. So, that's not all that complicated when you think about it, but to ask someone who knows nothing about a command-line, working effectively in an operating system, etc. and only knows about programming in Java -- maybe only servlet programming in Java -- to configure the server in the split case is confusing as all hell. +1 Anyone downloading a ZIP or tar archive containing a Tomcat installation would be confused if the archive contained not one but two top-level directories. Also, it would overwrite your split-configuration if you unpacked that archive in the same directory as when you first started. An installer program would have to explain what in the world the split configuration was. Have you ever tried to tell someone how to set up their email? POP versus IMAP? Most users have absolutely no idea what that is, and mail programs give no clue as to which one to choose. The same would be true of CATALINA_HOME versus
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 11/3/14 4:59 PM, Mark Eggers wrote:
1. Set up an unaltered Tomcat in one directory 2. Create a
duplicate directory structure somewhere else - to whit:
CATALINA_BASE-+ +-bin +-conf +-lib +-logs +-temp +-webapps +-work
You don't need all of that, but you can create all that structure if
you'd like.
3. Copy tomcat-juli.jar from CATALINA_HOME/bin to
CATALINA_BASE/bin
tomcat-juli.jar can still live in CATALINA_HOME/bin (unless is
something very specific to Netbeans deployments).
4. Copy all of the stuff from CATALINA_HOME/conf to
CATALINA_BASE/conf
You don't need it all. Really, only server.xml is required.
5. Edit CATALINA_BASE/conf/server.xml a. change the Server port b.
change HTTP/1.1 connector port c. change the HTTPS connector port
or comment it out d. change the AJP connector port or comment it
out 6. Edit tomcat-users.xml 7. Copy over the manager application
a. Copy over the application from CATALINA_HOME/webapps - OR - b.
Create a manager.xml in CATALINA_BASE/conf/Catalina/[hostname]
?xml version=1.0 encoding=UTF-8? Context docBase=location
of manager application in CATALINA_HOME
antiResourceLocking=false privileged=true useHttpOnly=true/
I've started doing this:
Context
docBase=${catalina.home}/webapps/manager
...
Since I never deploy from CATALINA_HOME, I can always rely on the
manager sitting there in the webapps/ directory. Actually, in order to
avoid synchronization issues between package-managed manager.xml and
whatever ships with Tomcat, we just wrote an XSL transform that adds a
docBase to the stock
CATALINA_HOME/webapps/manager/WEB-INF/context.xml. So we keep
up-to-date with anything that gets changed in there from release to
release.
To modify what extra JARs are needed for this CATALINA_BASE, just
add them to CATALINA_BASE/lib. This way your pristine Tomcat
remains pristine.
This is the one thing I haven't bothered to do yet for our
deployments. We need a JDBC driver and I usually just drop it into
CATALINA_HOME/lib and call it a day. Many times I've been bitten by
that when I install a new version of Tomcat and try to launch the
webapp, realizing that the JDBC driver wasn't in place.
We don't package-manage the driver and we don't use Maven or anything
like that to go auto-download dependencies or anything crazy like
that, so it's not currently a part of the application build process at
all.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUWApXAAoJEBzwKT+lPKRYEXcP/jCCRuwIxpgt9XcfYrclr8BZ
xGzkqvh8am/Tp/xo980ZuDiLOBLYJdVl0vXmgm0HWHlidpFbqkGJZG8uIDgXDBQ4
qSQGu9InvdwNTgn0sx/tlED9tfS2XDIJno6GUYMetjfaqwmGQEDtsKKdy5ycbigz
xMC91NJEqSgLbcCRp3WOTXGIJPJB14GQtPHGbMU7iOpLXcbxAgE3Ld3Sl2DYzl+H
oafNVVaTglV8ENQbrtKN55bJzco38tEcgJ6IhNbTPZ6XsV/sdwSAzBvrvhmHzPja
uCmnnp/AN9qa+rJUiY+DL9obJef1VxU4PKZ6MtW9PawGlClbQaVGedr/6T7NthjH
ZbJoGVr85KM0cFTYIuys0a4k3u8If1eMoFWXo5jGssAzTfOA10jRyAjByelJbbbT
R+KcZ4PuVOslhXK1J80Di47SEJvMFwdafFUBBRNOBKhv18hB9eeaETacJjB5ChGj
uLk7rdOktoDKmErrvDv5BIw+AhVCTeCP6gwphUZ2sFl6sMan5l8crDOCcfmn+Yod
zhvCOVvhEXaOYW9kXvr3pu3wlxKUzIborxtFnmVlvQMXMeBfJ6XqfK/vmBqrZK2V
8zHnn+eYZ4T/ClTKNxYdfu4Q5pHe1EDTxHP50bTET7zHHqtc25XCZfTHrmQwJJB9
bcEbkdyqN7hzqrRftt33
=vA7W
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 11/3/14 5:46 PM, Mark Eggers wrote: One of the issues I did run into when using tcnative-1.dll is that I got the following error message: 12.0.0.1 is not a recognized command, and Tomcat failed to start. Moving tcnative-1.dll out of the bin directory fixed the problem. When I specified JRE_HOME in setenv.bat, that also fixed the problem and allowed me to use tcnative-1.dll. I suspect some brokenness in the way NetBeans is handling the JRE_HOME environment variable, since I do have that set system-wide. That's weird. It looks like someone a) mistyped 127.0.0.1 for localhost and b) a script isn't working properly. Is this Netbeans-only, or does it happen with a stock Tomcat? It's also odd that it has something to do with using tcnative at the same time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWAr3AAoJEBzwKT+lPKRYou0P/1hnUCigz86EW8OsbNM68VG+ WXpaQOR389GL6t9WUjfaYg9wvkV4r7IbVwPIBGs9NNYtQjBP/TOrwq392smcuHL8 lsFVy1t4dOsjMeVv68wEBXylmoNY/4hnkuGK2Z9Qt28lBMgnEcvGRWaFcgMDNHiZ JsoXqTWmj8TfthZ02b+tklbIxIJizDTjPJcgnIxjGBHkjxCSplTODXNPkusmgc+x ddwGIGHyxYTT89z6OwONhKrlGON7m2NEmqHu9ggbBp4k6QCjBM917GSPHLqYumAt Z601xOZmJC/RX8sQbkQHSYTAX/oIQvR4ypH4J5pfZ3DidZtyIwmpSPVgy0vXTs3D B+iialoheRcE8Nldb4apGk4W3pZ1L5agz19Ru037soUxXWqwxEJtp38w5VzX4TcQ P8Qfd69l90N0ecA02qX+IJ3wnZmFtxLUb/c/XboABj0nWt8tOD8dQ+rEoKALUYMT aUKXATM+PwuT4z/QcYgcUFcdusHbwlVmftQSD4Atgo87hc4/+yDG4ryswhCodW2O R89KaQeDr4a8BQP4NmzD4XWgiH4ymSrBpXipaSxeoKq3eCI6ZubSNm8M9X1CF0E3 eqKNoBCmf9qtAA7m0Ku8dExJhtFfQtZCTiy0By+b5W2aV2BGU26ze3W2KNbh6ki/ q9NXGe01Z36YQMMavTYu =Zo4E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Chris, Leo, Vince, On Mon, Nov 3, 2014 at 5:42 PM, Christopher Schultz ch...@christopherschultz.net wrote: So, that's not all that complicated when you think about it, but to ask someone who knows nothing about a command-line, working effectively in an operating system, etc. and only knows about programming in Java -- maybe only servlet programming in Java -- to configure the server in the split case is confusing as all hell. +1 Anyone downloading a ZIP or tar archive containing a Tomcat installation would be confused if the archive contained not one but two top-level directories. Also, it would overwrite your split-configuration if you unpacked that archive in the same directory as when you first started. +1 An installer program would have to explain what in the world the split configuration was. Have you ever tried to tell someone how to set up their email? POP versus IMAP? Most users have absolutely no idea what that is, and mail programs give no clue as to which one to choose. The same would be true of CATALINA_HOME versus CATALINA_BASE. Everything has some degree of learning. New people are trying to learn two things at once, how something works as well as the why do it this way conventions that experienced users have implemented. New users don't understand the convention and want to learn it the hard way first before they can appreciate or even understand the convention. Agreed. The point I'm trying to make is that experts are experts because they have learned. Peeling-back the covers of Tomcat reveals those expert features like a split configuration. Being forced to use a split-configuration because it's what experts do is one sure way to generate a lot of noise on this mailing list. +1 I value my sleep and prefer to build new things instead of holding together configurations with chewing gum and duct tape. Oh, and rebooting all the time.) Anyhow, we can debate this all you want, but I will be -0 or even -1 to a default split-configuration of Tomcat unless someone has a really good idea for how to make it make sense to anyone on their first-touch. - -chris I would rather just point (windows) people to an example of a split configuration or any other configuration and let them implement it if they choose to do so, instead of getting Tomcat pre-configured. Part of the draw to Tomcat is that you have flexibility with how you choose to run it (script, service, windows installer, etc) +1 +1 Vince, the current configuration works great: 1) If you are a newbie administrator you are going to use easy-to-use-newbie-friendly configuration. It will get you started, it will get your application working, etc... Great starting point. 2) If you are developer (newbie or expert) and using IDE (Eclipse, Netbeans, IntelliJ) - you are going to use out-of-box tomcat configuration. Single Tomcat instance, no-split configuration. 3) If you are administrator that is upgrading Tomcat, you will just create a process to configure your instance with new Tomcat binaries and copy over the configuration file (most of the stuff is backwards compatible in server.xml within the point-version) + add any shared libraries to new tomcat/lib folder (JDBC drivers, etc...). Again, single-tomcat instance, no-split configuration necessary. Although, may people do like to split for easier upgrades and separation of concerns. 4) If you are administrator that is managing multi-instance environment, you can still get away with copying standard out-of-box Tomcat directory over and over again, for each instance separately. The hassle would be to do the upgrades on many instances. That's why we have CATALINA_HOME for shared stuff (binaries+libraries) and CATALINA_BASE for instance-specific configuration. And in this case you would know about the split directory setup option and would research how to do that effectively. My question is - why do you use CATALINA_BASE if you are using IDE (Netbeans)? If you are developer, there is no need to use split configuration. SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? Cheers! Neven
Re: Separation of CATALINA_HOME and CATALINA_BASE
Reply-to-my question:
On Mon, Nov 3, 2014 at 6:42 PM, Neven Cvetkovic neven.cvetko...@gmail.com
wrote:
SLIGHTLY-OFFTOPIC:
Although, I would love to see out-of-box setup for additional shared-lib
folder, something other than TOMCAT/lib with Tomcat default libraries.
Essentially, I would love to separate my customer shared libraries from
Tomcat default libraries. I guess - question would be where are
CATALINA_HOME/lib JAR files being loaded from? Can we add another directory
to scan for libraries to be loaded? Is that configurable?
I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
to now read:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar
What are you thoughts? Would it make sense to keep a separate directory for
shared libraries? Should we make it default - to encourage others to create
a directory if they want to. Default behaviour for
org.apache.catalina.startup.ClassLoaderFactory is to validate if the file
exists/isDirectory/isReadable? That might confuse beginners with a Warning
...
I guess Tomcat philosophy is to keep it simple, and extensible - so experts
that need to customize things they can, and it is simple and not confusing
for beginners.
What are your thoughts?
Cheers!
Neven
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-
Re: Separation of CATALINA_HOME and CATALINA_BASE
On 16/10/2014 19:11, vince.w...@thomsonreuters.com wrote: 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'm not sure that is any reason other than it has always been that way. It is something to consider for 9.0.x (work starting on that soon). An interesting question here is how smart should we / could we make the Windows installer? I have not looked to see if Tomcat 8 separates them. It doesn't. Mark I welcome your thoughts. Vince This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website.http://thomsonreuters.com/prof_disclosures/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Separation of CATALINA_HOME and CATALINA_BASE
Mark Thank you for such a quick response. Personally I don't have much interest in Tomcat's Windows installer. I am more interested in the directory structure that you get from expanding apache-tomcat-nnn.tar.gz Vince -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: 16 October 2014 19:44 To: Tomcat Users List Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE On 16/10/2014 19:11, vince.w...@thomsonreuters.com wrote: 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'm not sure that is any reason other than it has always been that way. It is something to consider for 9.0.x (work starting on that soon). An interesting question here is how smart should we / could we make the Windows installer? I have not looked to see if Tomcat 8 separates them. It doesn't. Mark I welcome your thoughts. Vince This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website.http://thomsonreuters.com/prof_disclosures/ - 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: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 10/16/14 2:43 PM, Mark Thomas wrote: On 16/10/2014 19:11, vince.w...@thomsonreuters.com wrote: 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'm not sure that is any reason other than it has always been that way. It is a bit easier to configure when CATALINA_BASE = CATALINA_HOME, especially for automated installers as well as the ZIP installer (aka just unzip into apache-tomcat-x.y.z directory). It is something to consider for 9.0.x (work starting on that soon). An interesting question here is how smart should we / could we make the Windows installer? If we added CATALINA_BASE ≠ CATALINA_HOME as default, the automated installer would have to ask where to install Tomcat and also where to install Tomcat's first deployment, which would be a bit confusing to people. The ZIP installer would need to have apache-tomcat-x.y.z plus something like apache-tomcat-deploy inside of it with Tomcat defaulting to use that as CATALINA_BASE. I don't see it working for novice users, and I don't see it working for advanced users, either, because they already know what they are doing. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUQDJvAAoJEBzwKT+lPKRYsY4P/36Dcuq0+2L1nL7LdGJus6+p 5VkJvzmlwFY3pfRNR4MHsXjEu8iBJV/QwDoplivZHd3KhcjoxGC8R6HKYeVHGub/ kSN1xeRqyPF1pqUJw7ejGKQaHP17UI4YeygxYCb4AKkh+L02Tkdsn+/JFGG5URmA NWlXFygxIE52HyXXfdEoV2KRY6M7frB2AFIVXOD/TpW36EO+O3QecCHQDTRZRDv1 1o5TQI++DzQeL/eBVYGg7bu/bC8jPAWC5cDBoQXE/H+iqBHbr9+C8tsSGEiYxZS+ mzC/UKhnfnNAp8PqzyLN/qLncwITE2A3QWxkDqFrk1sLlcKO2b2iXCkG+BiOewVw Iv1x8PJihvE9Tz7YZyv1MC6tVUZq5lBBviOfW+M2iHGPM5gy6j2gYMq1cxlTi1rD B2rs/0Ues0PPG7PjwDnSazZQtRrbiKYFIpLca8abgGQ8AUPlFqDtl7EN2azt+xjf Tc07l1W+86JZIkXUvcKbACkHcsHQg2bCcJtnIVaNfkwUnkVIHll/OyffgE53tL7W xzoBMGzxPNyp96mrvEbXhq+nyHRL+BCkEJDcbK2XSGKZWGTgWOxD4RUm9KUW3pNc orH8p7YQ7bj2PwQV3qZktDQ1dJw0IPLdbkhX3Nbr5Lp/80eCZXa9BFnrRjgQsgd6 Xv94kVsiBJvoh84wzViV =XhYF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
