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 :-)
Jens
Am 06.06.13 15:40, schrieb Jeffrey Janner:
-----Original Message-----
From: mailingl...@j-b-s.de [mailto:mailingl...@j-b-s.de]
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 file.
Then try to figure out where the messages are going (hint: it will be only 1 of
the files).
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
