You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2014/05/07 20:22:32 UTC
org.apache.logging.log4j.spi.DefaultThreadContextMap.localMap
Should org.apache.logging.log4j.spi.DefaultThreadContextMap.localMap be a
static?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: org.apache.logging.log4j.spi.DefaultThreadContextMap.localMap
Posted by Remko Popma <re...@gmail.com>.
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 <bo...@gmail.com> 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 <ga...@gmail.com> wrote:
>
>> Should org.apache.logging.log4j.spi.DefaultThreadContextMap.localMap be a
>> static?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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 <bo...@gmail.com>
>
Re: org.apache.logging.log4j.spi.DefaultThreadContextMap.localMap
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@gmail.com> wrote:
> Should org.apache.logging.log4j.spi.DefaultThreadContextMap.localMap be a
> static?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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 <bo...@gmail.com>