[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 matt.invoices at llmj.com  2006-02-08 17:06 -------
Hello, and thanks for the quick response!

Sure enough, Tomcat does limit its thrashing to fields that are static AND
final.  Good catch.  I totally missed that.

I will file the report with the Tomcat developers.  Maybe I'll suggest that they
look at the types of referenced objects before they null things out. Seems as if
a reasonable fix might be to only null those fields which refer to objects whose
classes were loaded via a disposable classloader.  I guess it depends upon what
type of memory leak they are really trying to address.

As for my "patch," I agree with you.  Option 1) probably isn't the correct
course of action.  My code wasn't written to be of production quality by any
means.  I just hacked it in to test my theory.  I will cover option 2) by
submitting a report to the Tomcat developers and seeing what they have to say.

As for option 3) ("cleaner solution"), yes, the release() bit does sound
promising.  Another option would be to have some kind of isValid() method on
SLF4JLog which is invoked by SLF4JLogFactory when it retrieves an instance from
its cache.  If that method returned false (meaning logger == null), the factory
could throw away the instance and create a new one.  The problem with this
option, of course, is that it again amounts to a bug fix to work around another
bug fix.  It would also leave a slow (and probably insignificant) memory leak in
the logger cache which could probably be avoided by taking your route of hooking
into release() (it might be able to proactively flush the cache of loggers for
classes which are being unloaded.)

The fact is, this is something that Tomcat probably shouldn't be doing. We'll
see what those folks have to say.

In the interim, would you like me to take a stab at option 3) and possibly
submit a patch?  If so, would you prefer that I focused on release(ClassLoader),
 or do you think that a stopgap like isValid() would be workable?

--Matt 

-- 
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.