DO NOT REPLY [Bug 9592] New: - Logger.getLogger(String, LoggerFactory) caching bug

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9592

Logger.getLogger(String, LoggerFactory) caching bug

           Summary: Logger.getLogger(String, LoggerFactory) caching bug
           Product: Log4j
           Version: 1.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Other
        AssignedTo: log4j-dev@jakarta.apache.org
        ReportedBy: jonwilmoth@hotmail.com


The problem lies in the existing org.apache.log4j.Hierarchy line 254.  The 
CategoryKey used to access the Logger instance cache only uses the 
String "name" param, which may only be a portion of the full category name if 
a custom factory is used.  So if the cache is not empty for String name, it 
returns the existing logger instance and does not call 
factory.makeNewLoggerInstance(name) which may produce a category with a  
different name.  Assuming a custom factory's makeNewLoggerInstance(String) 
always returns a Logger instance with the same category name given the same 
string parameter, you could cache with a CategoryKey of 
customLoggerFactory.getClass().getName() + name.  However if 
factory.makeNewLoggerInstance("myName").getName().equals
(factory.makeNewLoggerInstance("myName").getName()) isn't true you still have 
the same problem.  IMHO I think the caching needs to be put in the factory 
itself.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>