-----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 <
> ch...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
