You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by vi...@thomsonreuters.com on 2014/10/16 20:11:05 UTC
Separation of CATALINA_HOME and CATALINA_BASE
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.
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/>
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----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, <vi...@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
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Neven Cvetkovic <ne...@gmail.com>.
Thanks Chris!
On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz <
chris@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
> <ne...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Neven Cvetkovic <ne...@gmail.com>.
Reply-to-my question:
On Mon, Nov 3, 2014 at 6:42 PM, Neven Cvetkovic <ne...@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
Posted by Leo Donahue <do...@gmail.com>.
On Tue, Nov 4, 2014 at 10:36 AM, Christopher Schultz <
chris@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 <
> > chris@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Leo Donahue <do...@gmail.com>.
On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz <
chris@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Neven Cvetkovic <ne...@gmail.com>.
Chris, Leo, Vince,
On Mon, Nov 3, 2014 at 5:42 PM, Christopher Schultz <
chris@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Vince,
>>
>> On 11/3/14 4:12 PM, vince.webb@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 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUWATAAAoJEBzwKT+lPKRY974QAIaebAUpO4H6v9A/M5/iMWsY
3W70xqmXyrs7IgyBSxeRE/TAn0HgDsSw3/jJEjNn3tZ0a8Du2KU0LxpXtC1BhdMe
XUqFwMvfeQ8tSqbTX0qXSUpFwXhpR8gJTzN0oWY608iBerZ4xXHEeticj/TuDTpZ
S8o573iFINnJ6V+QCTxRGe7D2LG1mDD8NoGPgN5lHdGCVNWuWhDdmegmhhZ6O994
lcWulEgbHIVuh8u2DdNdL12RabtO7NUu1k7UKongmKpgQQMagace89OGMAoHRkYZ
YelgwEMK7yYOvbPkxt9QpvYvY1Dqo6aXEWawW4GMRmjLHYN7Qy0bXDURbhjODO6d
gFRyyIvzRgrvOFM72OV5rSFnjoON41vmXc6cWsz23ITkkiWFvgJ5lcT0pljcQ/P1
PKv2wT7xxgOhPfZHhTCSYkJ8ZQDApPxMMOxGwI5kOSsRWEVt4ALh0k8Kv0sd36WF
1hpC/nfwPRwBW7xP+4ZVfafJiFViodFcn/jSztCQmcvPjtJmFL0Dssg8TdVYq0kp
eGMAPdpH3zyddktlWZsOR9YM8LK082reOQ7K8V72qFbQU+JQWr8GtV7icBPxPGDZ
ggJJ6m5lyNR8XilGR2+1I/147BJ5tXAZrHfH2LtZSg+QR85l5dZjuo8DjBvv8l1K
0FFPP78XexZkKqqWgpfX
=Kqab
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Leo Donahue <do...@gmail.com>.
On Mon, Nov 3, 2014 at 3:33 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Vince,
>
> On 11/3/14 4:12 PM, vince.webb@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.webb@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 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
> make use of CATALINA_HOME / CATALINA_BASE.
>
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUWAfLAAoJEBzwKT+lPKRY7nQQAJRNmv/8oK2qBahwUOaS0xBF
IFkYKl8ftdNVc+XRG914KV6M+SfOu6gQB2yaqS2S4wCoE9sSnTVbbAxkmhP2vVZG
RTaCFnc7ZPawhiRolMCPRycPipc/2Bgl5RkhMDVmEJ4ntg1LL3YKseqSBQabtPWS
/LiRgd53RsQxbboqC9BYgCMiQ/wIEofz7vopPdVvBxkjLI5kvZ7PqoqXcdKkF2RY
bpiu+fb8CaC0kdkZPZrsOhUwlce/MzhsTs7xKgco3EKwNJfBefw7/cZZiWidoZqh
2ENzafG76ySxmwLx3xEqXmGrO8vKEh2qB8u7BTu+C7EtNwF7T5rX+1WDywlnhq/R
fioC0GVneGagjfG0NQ49T7tueI6bo8l6UdG52JByx3BAkcAcYmFR1J4XTlcfxdoG
uA6rEe2Rk4iIcRKEMVK5xwmqFQLrmqUvoB2JTW2t10F4BrglPP8UZVA9GudJ7NgQ
dVzhz1s30Xs3qqJgj1kAJxhpmwlydZ+7nQkNU9VsledGT5cpZBks7HJtbNv+ZdsQ
jey0vtIMven+gjt7qqaUXF7XBZDfP7NxTWD1jq/FsG9Z9rMKkz6gvDLcf4JWpo+a
4VrsOU4w1X+6uLHZscp0BhavuBlfydj43uwoXG/06MtlndcgvR1pNflMztt3sI8n
BItN1OnqxXIcumXr/cWq
=4Weg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----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.webb@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 / availability numbers.
> 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 make use
of CATALINA_HOME / CATALINA_BASE.
Maybe a step-by-step Wiki article is in order.
> -chris
. . . just my (put support hat on) two cents worth
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJUV/6jAAoJEEFGbsYNeTwtsA8H/j1ULVdRaNDJukRP5G7JJpz8
b/WqnbzFiSPGNIOacZTE+xIzf9lnatbj6pGfxrlPzy6KvoP+tsBYk5wAwxAO285R
4+BEBOmDU29J2kcAg4zWw6mTF/qq8gSLu0CkiodwehFQhA5qbADoPX1HlE4JEYoP
WMRKjnO+nyy4Ah/h45Tq0t/L2Ny3Thb/IwRuIGQheRrHPOQhRnSZFppvpH1bSjjW
Vh7m31Hk5LYnKGAQ0M2fDAcmuAkU/oyei7GjyWU3VKb8nVQufqSJUxjkNrNJz58s
5ZgmVL/GubXzHkdJ9mIBe/KdSRM3CLHCaTLfeW8P5fGbtjDsKUzJDJmzuLLDXDQ=
=pdNJ
-----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
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Vince,
On 11/3/14 4:12 PM, vince.webb@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
GAD5gf3FvX0sAs5UnNNQTe4gf++euhnc8OX5a3CieUxGDb+eRUnRzsdAElpe0Aff
f++0GKikRzyyYdRXIxna
=+BXM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Separation of CATALINA_HOME and CATALINA_BASE
Posted by vi...@thomsonreuters.com.
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.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, <vi...@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
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----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, <vi...@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 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.
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJUWAXVAAoJEEFGbsYNeTwtJ5IH/RPItbyYnWsuTCXkDpbQeNva
aXXfW93PH3RJDwYAjcq0merTOVWh9Ar3Ux7Ng+meV/Q4xFi4dwQ1B6ukmmvAd4oh
p4sp2uiXjj1aP/Wwku4kOw2U3Cs9NND4g1iuaCiEmeUsNUElBmS3xItRBhyBXRw/
jKa2xS9a6XH9bl+RJn5aA9gC97YNJ2n71au4FTGc6zco/1syyDTaqpZEnHbmcXWI
PGY+dp6Sf+dCIeJIxBE0n9ml9EWsViHNl+3NElS7wO6BqwbEhLIQHJVTVVpPARsh
Tr2tZcOIdsGRWxw6+ZrAbdck8k1eizZl9Uhta1Pj6K+mtWVpafZxR0PG1R516T8=
=xoHc
-----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
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Neven Cvetkovic <ne...@gmail.com>.
Vince,
On Mon, Nov 3, 2014 at 2:38 PM, <vi...@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Vince,
On 11/3/14 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.
>
> 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
0+p5tBXbSTqc3ettoBxv
=Vx6D
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Separation of CATALINA_HOME and CATALINA_BASE
Posted by vi...@thomsonreuters.com.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@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.webb@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Mark Thomas <ma...@apache.org>.
On 03/11/2014 19:38, vince.webb@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Separation of CATALINA_HOME and CATALINA_BASE
Posted by vi...@thomsonreuters.com.
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_toasted@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 <vi...@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
Posted by vi...@thomsonreuters.com.
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_toasted@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 <vi...@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
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----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 <vi...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-10-16 22:11 GMT+04:00 <vi...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Separation of CATALINA_HOME and CATALINA_BASE
Posted by vi...@thomsonreuters.com.
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:markt@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.webb@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 10/16/14 2:43 PM, Mark Thomas wrote:
> On 16/10/2014 19:11, vince.webb@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
Posted by Mark Thomas <ma...@apache.org>.
On 16/10/2014 19:11, vince.webb@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org