tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Breitenstein <>
Subject Re: Best practices for shared classloader use?
Date Thu, 06 Jun 2013 16:47:33 GMT
Hi Jeff,

You are rigth. When moving jars's configuration and resources have to 
move, too. But as others pointed out analysation of the mem usage is by 
far more important. Maybe buying some mem for a couple of dollars and 
forget about the shared class loader at all is a better and less hair 
graying approach :-)


Am 06.06.13 15:40, schrieb Jeffrey Janner:
>> -----Original Message-----
>> From: []
>> Sent: Tuesday, June 04, 2013 11:25 AM
>> To: Tomcat Users List
>> Subject: Re: Best practices for shared classloader use?
>> Hi Don!
>> Usually each Webapp has its own classloader thus two webapps can have
>> different versions of the same class. Classloaders are chained so if a
>> class is not found search continues in the next classloader. Shared
>> just means one classloader is used by different webapps thus you may
>> run into trouble if each webapp requires a different class version
>> (changed method signature) as you can not predict which version you
>> get. As long you can align the shared libs across all webapps this is
>> not an issue. I do not see your static field problem, though?
>> Share functionality like using the same jars? If all use the same
>> version you can push it to the shared imho.
>> Jens
> Jens,
> Statically declared variable are a big problem with the shared class loader.
> Check the archives for this topic. You only need to go back a month or two.
> If you doubt me, try sharing log4j among a bunch of apps, each with its own properties
> Then try to figure out where the messages are going (hint: it will be only 1 of the files).
> Jeff
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message