Unfortunately I haven't. For right now, I'm calling the makeNewLoggerInstance method on the factory directly. I've implemented my own caching inside the factory, although Logger.getLogger(String) also caches so it may not be necessary.
Jon -----Original Message----- From: Xinjian Xue [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 3:23 PM To: 'Log4J Users List'; [EMAIL PROTECTED]; Jon Wilmoth Subject: RE: Bug in getLogger(String, LoggerFactory)? Jon, I have the same problem as you reported. Have you got some answer or some solutions? Thanks. ------------------------------------------------------------- Xinjian Jack Xue, Phone: 317 554 7622 -----Original Message----- From: Jon Wilmoth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 10:03 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug in getLogger(String, LoggerFactory)? I'm using a custom LoggerFactory and not getting the expected behavior. After taking a look at the source, the Hiearchy class's implementation of getLogger(String, LoggerFactory) doesn't account for the LoggerFactory producing logger's with different names. The CategoryKey used to cache is always the name of the string param and not the LoggerName. Is this a bug? I've attached a unit test which illustrate the problem. Logger getLogger(String name, LoggerFactory factory) { //System.out.println("getInstance("+name+") called."); CategoryKey key = new CategoryKey(name); // Synchronize to prevent write conflicts. Read conflicts (in // getChainedLevel method) are possible only if variable // assignments are non-atomic. Logger logger; synchronized(ht) { Object o = ht.get(key); if(o == null) { logger = factory.makeNewLoggerInstance(name); ... } Jon Wilmoth Technical Specialist Starbucks Coffee Company -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
