[
https://issues.apache.org/jira/browse/LOG4J2-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13861501#comment-13861501
]
Remko Popma commented on LOG4J2-479:
------------------------------------
Hmm... I'm not sure how to proceed here.
On the one hand, if an application needs some threads to log with ThreadContext
info and some threads to log without ThreadContext info, then it would be
reasonable to ask the application to control this. (It knows how to put stuff
into the ThreadContext somewhere, so it should know how/when to take stuff out.)
On the other hand, it is interesting that {{DefaultThreadContextMap}} uses an
{{InheritableThreadLocal}} while {{DefaultThreadContextStack}} uses a plain
{{ThreadLocal}}.
It seems to me that the map implementation is inheritable on purpose and I
hesitate to change this.
Ralph, can you shed any light on this?
> Use of InheritableThreadLocal in Map ThreadContext is dangerous and unhelpful
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-479
> URL: https://issues.apache.org/jira/browse/LOG4J2-479
> Project: Log4j 2
> Issue Type: Bug
> Reporter: MK
>
> Described here http://logging.apache.org/log4j/2.x/manual/thread-context.html
> The use of InheritableThreadLocal creates subtle and hard to track bugs while
> not really adding much useful. It is counterintuitive -- I don't see why
> would anyone expect logging context to be inherited. But it breaks down
> completely when used with Thread Executors.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
