Good question. In the current usage, the ThreadContext class has a static reference to a DefaultThreadContextMap. So essentially DefaultThreadContextMap is a singleton and the localMap ThreadLocal could be either static or non-static, it doesn't matter.
Perhaps we can rephrase the question as: Is there any potential future use case where the ThreadContext would swap its reference to another DefaultThreadContextMap instance, and how should that behave? I would argue that such a swap would want to replace the existing values, so a non-static field is more appropriate. (But again, this is fairly academic as long as DefaultThreadContextMap remains essentially a singleton.) On Tue, May 13, 2014 at 8:11 AM, Matt Sicker <[email protected]> wrote: > I would certainly say that in like 99% of cases (probably more), > ThreadLocal variables are meant to be static (otherwise I'd tend to use a > different data structure like AtomicReference). Anyway, the documentation > makes this a little strange, but I can't see a reason to use a ThreadLocal > instance field over a static field. It might have been set that way due to > the optional use of InheritableThreadLocal, but that class deals with > thread inheritance, not class inheritance. > > > On 7 May 2014 13:22, Gary Gregory <[email protected]> wrote: > >> Should org.apache.logging.log4j.spi.DefaultThreadContextMap.localMap be a >> static? >> >> Gary >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > Matt Sicker <[email protected]> >
