[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


listid at qos.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From listid at qos.ch  2006-02-08 13:31 -------

Matt,

First, thank you for this extremely well-researched bug report. Your
clear and detailed description of the problem is also noteworthy.

Looking at the source code of CollectionFactory one can see the line:

private static final Log logger = LogFactory.getLog(CollectionFactory.class);

Note that the field is both static and *final*. The fact that it is
both static and final has its importance because the nullInstance()
call in org.apache.catalina.loader.WebappClassLoader is only made for
static final fields. Had the field been just static, the private logger
field in org.apache.commons.logging.impl.SLF4JLog would not have been
set to null with the undesirable consequence that you have described.

Thus, it looks like the private logger field of o.a.c.l.impl.SLF4JLog
instances would be set null only if the o.a.c.l.Log fields in unloaded
classes are both static and final, instead of just static. 

If Tomcat developers feel the need to set to null the contents of
static final fields of unloaded classes, then we can 1) apply your
patch, or 2) file a bug report with Tomcat, or 3) attempt to find a
another, perhaps cleaner solution.

I must confess that I am uneasy about option 1). It does not seem wise
to fix a bug by circumventing the effects of code trying to fix
a different bug. On the other hand, your patch shows that the problem can
be solved which is very encouraging.

Filing a bug report with Tomcat will at least let them know about the
side effects of their fix.  Would you prefer to file the report, or
should I?

As for the third option, we could take advantage of the fact that
Tomcat calls the release(ClassLoader) method of o.a.c.l.LogFactory
class when it unloads classes. When the release(ClassLoader) method is
invoked, SLF4J's implementation of o.a.c.l.LogFactory could try to
rebuild null fields. (Admittedly, this is not that different than your
workaround.)

Comments?



      



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