Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: >> Fix some logging related memory leaks. This fixes 41272 and the root > -1. Getting a logger has, AFAIK, a possibly significant cost. Since > getting a RD is a very common option, this is not acceptable. I took a look at the commons-logging code. The first call for a context will be expensive as the logger has to be created. After that it is: - one call to getContextClassLoader() (via reflection) - two hashtable look ups - some wrapper code I knew it used getContextClassLoader(). I didn't realise it was via reflection so I agree with you about the performance hit.
> If you really want to fix this non issue (which will simply happen > elsewhere in more insidious form), I don't view memory leaks and loggers for one context logging messages for a different context a non-issue. Given all it takes for this to occur is to put log4j in a webapp this is likely to affect a lot of people - including me ;). I am happy to spend the time fixing these issues and any others that crop up in the future. > I think you should find another way (removing a > lot of the logging would be good, since it's lame debug which should not > be there, and maybe use wrapper.getLogger). I like the wrapper.getLogger() idea. I don't have time to look at this tonight - I'll take a look tomorrow. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
