commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <bes_commons_...@yahoo.com>
Subject Re: logging: WeakHashtable
Date Tue, 16 Nov 2004 06:12:11 GMT
OK, been playing with different classloading
configurations to see if the loader gets stuck in map.
  Good new/bad news.

1) As you'd expect,
LogFactoryTest.testReleaseFactories() will definitely
work because the dummy classloader I use in the call
to getFactory() was not the contextClassLoader when
LogFactoryImpl was first loaded.  Duh.

2) Fixed that by ensuring that a trivial test
classloader was the thread context loader when
LogFactoryImpl was first loaded.  TestClassLoader is
as follows:

private static final Class TestClassLoader
  extends ClassLoader {

  private TestClassLoader(ClassLoader parent) {
    super(parent);
  }
}

Again, the test passes.  This is because the
TestClassLoader delegates to its parent, so the
LogFactory holds a reference to the parent, not the
child.  Good news.  I expect this would be a typical
situation with things like EJB classloaders and all
others that follow the Java2 delegation model.

3) Beefed up TestClassLoader by overriding loadClass()
so it was able to load LogFactoryImpl itself and
wouldn't delegate to its parent.  This simulates a web
app situation, where the web app classloader ignores
normal Java2 classloading and may find its own copy of
commons-logging in WEB-INF/lib.  Bad news.  As you
expected, the test fails because the test classloader
is kept in the map by the hard reference from
LogFactoryImpl.

So, it seems like a hard reference in the map to a
LogFactory is mostly a problem for webapps that
include commons-logging in WEB-INF when it is already
available on the server classpath.  Bad practice in
general to do this, but people do the darnedest
things.  I know Tomcat and the embedded Tomcat in
JBoss both guard against this problem by calling
LogFactory.release() when they undeploy webapps. 
Don't know about other webservers.

(BTW, the problem with JBoss that led to Bug 31286 is
related to EJB deployments.  commons-logging is on the
JBoss server classpath (specifically in the
UnifiedClassLoaderRepository) due to its use in
embedded Tomcat, so the classloader situation should
be analogous to #2 above.  JBoss doesn't call
LogFactory.release() when undeploying EJBs, because if
embedded Tomcat is not deployed they can't be sure
LogFactory will be available).

- brian


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message