[slf4j-dev] [Bug 15] SLF4JLog 'logger' field nulled by Tomcat 5.5.15

[bugzilla-daemon at gil.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=15





------- Additional Comments From listid at qos.ch  2006-02-08 19:49 -------
Considering that SLF4J does not keep track of class loaders, our
reaction to invoking release(ClassLoader) by Tomcat would necessarily
involve checking all SLF4JLog instances. But more importantly, we
would be undoing what Tomcat did a few lines back in its code. Can
code get more confusing than that? 

The isValid() idea seems quite good. I can't tell if it is better than
hooking with release(). An important point to keep in mind is that an
invalidated SLF4JLog instance may be referred to by objects or classes
other than those classes unloaded by the WebAppClassLoader. So an
invalidated SLF4JLog object cannot be discarded and recreated as a
different instance. The *same* instance must be rebuilt which I think
can only be done when release() is called. Alternatively, SLF4JLog
instances could be self-healing, as in your initial patch.

Horrendous as all these fixes may be, I can't think of anything better
than what has been suggested thus far. It looks like we are confronted
with many evils and must choose the lesser weavel. In the best of
worlds, the Tomcat folks would revert their bug fix. Let first see
what they have to say.



-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.