tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <its_toas...@yahoo.com.INVALID>
Subject Re: Separation of CATALINA_HOME and CATALINA_BASE
Date Mon, 03 Nov 2014 21:59:12 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vince,

On 11/3/2014 1:12 PM, vince.webb@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.cvetkovic@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.webb@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
> 
> ---------------------------------------------------------------------
>
>
> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUV/qvAAoJEEFGbsYNeTwtkjIH+waIr9cuTFM5i1tWX9Oulh3Q
gj3ImZgdvq27tc6bke8yoNWQcbp7lZsIlbIDVWOa2nxWHkXOHQs+4o4HzGxMInFu
Q6SxJEGVtPrOU9c9pPpT5SBQyxVSoLhAtxPC4D3zqBWzU6DHkP3tjP8fqkDmB/z8
oJtE7Ml+xIF4fsGIG5whpA3/YvPLs3p5I58subWJhDf5ahKYdAqsU2hDNFnFwPn1
kFY6sCkr23hWauHXDFA7ZM00v19mizIbONHh/M5wWbvZTvBp9Ay4u8kVjgfuzz1V
dD91W1q5ibnje6DXeSnEdFrBUtmpSYre1On+kL3Q+pxgzZwjdFHIwkZB4xWA6jw=
=+i7n
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message