old issue of log4j trying to use the previous classloader

[Ceki Gülcü <ce...@qos.ch>]

Hello,

At 2004-01-23 11:54, just 4 minutes after bug number 26372 [1] was
filed, Remy Maucherat threw it out, saying:

   This is the old issue of log4j trying to use the previous classloader
   (reloading will create a new classloader to load class definitions;
   see bug 3888 [2]). Maybe it would be good to leave this bug open so
   that people can complain using it, rather than file
   duplicates. However, I'd like everyone to know that the "bug" will
   never be fixed.  You can probably fix the problem by putting log4 JARs
   (and the necessary commons-logging wrapper classes) inside the webapp
   repository.

What old issue of log4j trying to use the previous classloader is Remy
referring to? I am not aware of any log4j code that holds on to
classloader references. If Remy was misinformed, he should retract his
previous statements about log4j holding classloader references. On the
other hand, if his claims are substantiated, I would be happy to study
the evidence and work to correct any mistakes.

Latest evidence [3] indicates that the java.lang.ThreadDeath problem
has it's root causes in classloader references held by
commons-logging. As the commons-logging dynamic discovery mechanism is
based entirely on tracking various classloaders, there is no doubt
that commons-logging holds on classloader references.

For the sake of our users, I would appreciate if tomcat-developers
could shed more light onto the matter.


[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=26372
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=3888
[3] http://issues.apache.org/bugzilla/show_bug.cgi?id=27371


-- 
Ceki Gülcü




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