tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Separation of CATALINA_HOME and CATALINA_BASE
Date Tue, 04 Nov 2014 18:32:06 GMT
Hash: SHA256


On 11/4/14 1:05 PM, Neven Cvetkovic wrote:
> Thanks Chris!
> On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz < 
>> wrote:
>>> I guess, it's easy to add new directories to 
>>> TOMCAT/conf/ 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
Version: GnuPG v1
Comment: GPGTools -


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

View raw message