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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
