Hi Jon, I got what you are saying.
Now, as for the present design of CategoryKey I could think of the following reason: Not all usages of log4j want to follow the classname hierarachy, our case for example. In this scenario, it would be a issue for caching the FQN of the category in the CategoryKey class as I may follow a custom Hiearachy structure to identify the loggers/categories. And I'm doing that by the design I put here by having extended LogManager to return my desired Hiearchy. What's your take on this? Thanks & Regards Sridharan -----Original Message----- From: Jon Wilmoth [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 11:39 PM To: 'Log4J Users List' Subject: RE: Bug in getLogger(String, LoggerFactory)? The problem lies in the existing code base (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. 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.makeNewLogg erInstance("myName").getName()) isn't true you still have the same problem. I think the caching needs to be put in the factory itself. As for your design, it's a lot more complicated than simply calling factory.makeNewLoggerInstance directly and adding caching to it. I don't know what other value-add behavior you've added to your custom, LogManager, RepositorySelector and Logger class, but you're risking being too far off the upgrade path for my liking. Jon -----Original Message----- From: Sridharan Vembu [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:32 PM To: Log4J Users List Subject: RE: Bug in getLogger(String, LoggerFactory)? Hi Jon and Xinjian, I'm also using a custom LoggerFactory and also I've customized the LogManager,RepositorySelector and Logger classes, in a way that, I'll always get a Logger instance from my CustomLogger.getLogger(), which follows the following path to make a new instance from CustomLoggerFactory. CustomLogger.getLogger(name)->CustomLogManager.getLogger(name, customeLoggerFactory)->customRepSelector.getRepository(hierachyname).getLogg er(name,customeLoggerFactory)->Hierachy(name,customeLoggerFactory). And from my sample application, I have created two hierarchies and some 5 loggers in both hierarchies. And I'm able to get the different instances. Could you please explain me on the following points; 1. Are you following a similar approach or some other? 2. Where exactly you are getting a issue here? Waiting for your inputs, so that I can also rethink of my design. Thanks & Regards Sridharan -----Original Message----- From: Xinjian Xue [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 01, 2002 3:53 AM To: 'Log4J Users List'; [EMAIL PROTECTED]; '[EMAIL PROTECTED]' 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
