tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Separation of CATALINA_HOME and CATALINA_BASE
Date Mon, 03 Nov 2014 22:55:07 GMT
Hash: SHA256


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, 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/ 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/
>> 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 $
>> 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/" 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 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.

Can Windows do parallel versions of Java anymore? You used to be able
to do it, and then people ended up with every patch version of Java
between 1.6.0 and 1.6.55 installed side-by-side and that caused some
irritation. Then the Java installer started deleting the old versions
that were installed, which of course will break anything that doesn't
"search" for the currently installed (or updated) Java version.

It looks like Apple got the Java deployment strategy right: install
whatever you want and have a utility that knows where to find JVMs
that match certain criteria.

> Rebooting is also not nice for reliability / availability numbers.

(I just meant that rebooting is evidently a way of life for Windows
admins. Everyone I know that admins anything other than a desktop
system seems to have to reboot either weekly or nightly just to keep
things running without weird stuff "happening". Our *NIX servers run
for months or years without being rebooted. Only upgrading the kernel
really requires a reboot.)

>> 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.
> If I was a voting member, I would definitely be -1 for this change.
> It makes the default use case (get up and running quickly) much
> more difficult, and provides no advantage for those people who do
> Maybe a step-by-step Wiki article is in order.

I've often thought that burying the split-configuration in RUNNING.txt
was not a great strategy. It's nice to have it *in* the downloadable
package, but having it online (with hyperlinks, in-depth discussion of
the hows and whys, etc.) would be great, too. The problem is with
documentation getting out of sync. Someone updates the RUNNING.txt
file but not the web site or vice-versa. Yes, there's some oversight
from other committers and members of the community, but everyone is a
volunteer and sometimes we're not all paying close attention.

- -chris
Version: GnuPG v1
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message