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 "Remko Popma (JIRA)" <ji...@apache.org> on 2016/08/01 09:50:20 UTC
[jira] [Comment Edited] (LOG4J2-1010) Injectable context properties
[ https://issues.apache.org/jira/browse/LOG4J2-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401775#comment-15401775 ]
Remko Popma edited comment on LOG4J2-1010 at 8/1/16 9:49 AM:
-------------------------------------------------------------
I guess we need to make a choice here. If a configuration uses the context map lookup, like this:
{code}
<Properties>
<Property name="userId">prefix-$${ctx:loginId}</Property>
</Properties>
...
<File name="file" fileName="application.log">
<PatternLayout pattern="%d %p %c{1.} [%t] $${ctx:loginId} %m%n" />
</File>
{code}
What is the expected behaviour for this lookup when a different context injector is configured which *does not use the ThreadContext* (say for Scala Finagle or async servlets)? If a LogEvent is available we can use the event's ContextData or context Map, but if no LogEvent is available, should the lookup
* search the ThreadContext Map?
* search the new context provided by the injector?
The first option means that the {{$\{ctx:key\}}} lookup is for ThreadContext only, and other contexts need to define their own lookups, e.g. {{$\{finagle:key\}}}. This is clear and unambiguous, but users would need to change the configuration when a new context injector is configured.
The second option may be more convenient. We would need to update the documentation to say this lookup is for the _currently configured context injector (by default, ThreadContext)_. If users want a lookup for a different context, nothing stops them from creating a custom lookup like {{$\{finagle:key\}}}.
was (Author: remkop@yahoo.com):
I guess we need to make a choice here. If a configuration uses the context map lookup, like this:
{code}
<File name="file" fileName="application.log">
<PatternLayout pattern="%d %p %c{1.} [%t] $${ctx:loginId} %m%n" />
</File>
{code}
What is the expected behaviour for this lookup when a different context injector is configured which *does not use the ThreadContext* (say for Scala Finagle or async servlets)? If a LogEvent is available we can use the event's ContextData or context Map, but if no LogEvent is available, should the lookup
* search the ThreadContext Map?
* search the new context provided by the injector?
The first option means that the {{$\{ctx:key\}}} lookup is for ThreadContext only, and other contexts need to define their own lookups, e.g. {{$\{finagle:key\}}}. This is clear and unambiguous, but users would need to change the configuration when a new context injector is configured.
The second option may be more convenient. We would need to update the documentation to say this lookup is for the _currently configured context injector (by default, ThreadContext)_. If users want a lookup for a different context, nothing stops them from creating a custom lookup like {{$\{finagle:key\}}}.
> Injectable context properties
> -----------------------------
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.2
> Reporter: Mikael Ståldal
> Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org