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]>
