[
https://issues.apache.org/jira/browse/LOG4J2-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15345743#comment-15345743
]
Remko Popma commented on LOG4J2-1010:
-------------------------------------
I'm trying to understand the use case better... The original request mentioned
Twitter Finacle. I understand this is a heavily asynchronous services framework
where Futures play a central role. Application code has no control over which
threads execute the request so if you want to have some shared information in
all logging statements resulting from the same request, storing this
information in a ThreadLocal will not work. I was wondering how other people
solve this. Surely we are not the first to run into this problem...
It turns out that Finacle has a concept called a
[Context|http://twitter.github.io/finagle/guide/Contexts.html]:
{quote}
Finagle uses
[Contexts|https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/context/Contexts.scala],
which give you something akin to Java’s ThreadLocals across asynchronous code.
They give you access to request-scoped state, such as a request’s deadline,
throughout the logical life of a request without requiring them to be
explicitly passed. Finagle explicitly manages them for you across threads and
execution contexts such as Future composition, FuturePools, Timers, and in some
cases — across the client/server boundary.
{quote}
If this is for the Scala module, then one way would be for the Scala module to
provide a Context-based mechanism to hold some request-scoped data and make it
visible to all log events in the same way that ThreadContext does in
log4j-core. In log4j-core, the ThreadContext information is merged into the
LogEvent when the LogEvent is initialized. This is currently hard-coded to take
the [LoggerConfig
properties|https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/LoggerConfig.java#L332]
(interpolated every time a log event is created), and merge these with the
Map<String, String> returned by ThreadContext.getImmutableContext(). One idea
would be to make this mechanism pluggable so that the Scala module can take
information from the Scala Context instead of the ThreadContext.
Another way would be for the application to do this manually on every logging
call. The application would need to store this information in some data
structure (let's say a map) and explicitly pass this data between threads and
execution contexts. Then every time the application logs something it would
pass this data as one of the arguments to the logging call. It seems to me that
this would put a fairly large burden on the application, but if I understand
correctly, this last mechanism is what Mikael is shooting for. Unless I
misunderstand...
> Possibility to set ThreadContext values in calls to Logger method
> -----------------------------------------------------------------
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.2
> Reporter: Mikael Ståldal
> Attachments: properties.patch
>
>
> It would be useful to have some logging methods in the Logger interface to
> set ThreadContext values for a single log message only.
> In an asynchronous environment, using ThreadContext as currently defined is
> not so useful since JVM threads might not be coupled to the logical flow of
> the application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
