tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject Re: Separation of CATALINA_HOME and CATALINA_BASE
Date Mon, 03 Nov 2014 22:46:45 GMT
Hash: SHA1

Neven and Vince,

It's dead-simple to run under NetBeans. Just unzip and go - use the

On 11/3/2014 12:21 PM, Neven Cvetkovic wrote:
> Vince,
> On Mon, Nov 3, 2014 at 2:38 PM, <>
> 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
> 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
>> 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

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

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

In short, works fine, tastes great.
Version: GnuPG v2


This email is free from viruses and malware because avast! Antivirus protection is active.

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

View raw message