On 24.09.2010, at 17:04, Jacob Kjome wrote: > Since Log4j must support JDK1.4 (actually, still 1.3, I believe), I don't see > how we could use JDK1.5+ ThreadLocal.remove()?
I suspected something like this...I was actually surprised to see that there's still development activity here. What I see sometimes with other libraries which have similar constraints is that they detect JVM versions and act accordingly (in some cases issuing commands via reflection). > That said, there are other ways of cleaning up ThreadLocals that don't > require remove(). For examples, see CrazyBob's "Hard Core Java: ThreadLocal" > from back in 2006 [1]. Log4j could utilize CrazyBob's suggestions and > provide an MDC cleanup method to allow users a chance to clean up. Thoughts? From a client application developer's point of view there should be "some means" to clear this that works reliably on somewhat modern JVMs. Please note that - Tomcat only runs its clean-up operations when it runs on Sun JVMs - only Sun JVMs seem to have that memory issue because they load classes into permgen - not clearing MDC ThreadLocal only becomes an issue when frequently hot-deploying an application in a container (something you don't wanna do in production environments anyway) As a client application developer I care because customers are breathing down our neck to get this fixed nonetheless. Marcel -- Marcel Stör, http://www.frightanic.com Couchsurfing: http://www.couchsurfing.com/people/marcelstoer O< ascii ribbon campaign - stop html mail - www.asciiribbon.org --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
