Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 10/10/2009 9:26 AM, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: [OT] tomcat 5.5.25 shared lib and sharing webapp jars
My direct experience that had led me to believe that ClassLoaders
keep lists of their loaded Classes is that a WebappClassLoader
held across a webapp restart (due to inadequate cleanup by the
webapp) results in all Class objects loaded by that
WebappClassLoader staying in memory, essentially forever.
I think you are correct about Tomcat's WebappClassLoader; it has to
maintain the set of the classes it has loaded since it breaks the
normal Java delegation rule, and can't simply ask its parent for the
class.
Is that because the primordial ClassLoader will hand-out references to
any class already loaded by any ClassLoader, so if null is returned,
then the current ClassLoader knows it needs to do its own loading (if it
can)?
The JVM itself keeps track (outside of the heap) of all loaded
classes so that classloaders that follow the standard delegation rule
don't have to.
Also, the WebappClassLoader has to be able to re-load classes that are
updated during runtime. In order to do that, it needs to know what has
been loaded and when.
Not that it was my thread to begin with, and not thjat it's really
dramatic either, but I suppose you guys must realise that you lost me,
like, about 15 posts ago ?
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
