logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1010) Injectable context properties
Date Mon, 01 Aug 2016 09:50:20 GMT

    [ 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


Mime
View raw message