[
https://issues.apache.org/jira/browse/LOG4J2-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15349081#comment-15349081
]
Remko Popma commented on LOG4J2-1010:
-------------------------------------
Good questions.
* I like to see the ContextDataInjector as the thing that is responsible for
populating the LogEvent's ContextData. So I would say let the
ContextDataInjector implementation add the configuration properties. But I can
be convinced otherwise.
* Still undecided on how to register a ContextDataInjector. Who would use a
custom ContextDataInjector? I imagine this would most likely be the authors of
asynchronous frameworks that use Log4j 2 as their underlying logging framework.
If we make this a plugin then their users would have to configure the
framework's injector in their logging configuration. This feature seems a bit
too "internal" to ask users to configure it, but I'm interested to hear other
opinions.
* I was thinking to just have one. That would be easier to implement. The
default implementation (ThreadContextDataInjector?) would copy items from
ThreadContext. Other implementations can override or replace the default
implementation.
* Agreed. The code from Log4jLogEvent.createMap() will move into
ThreadContextDataInjector.
> Injectable context properties
> -----------------------------
>
> 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
> 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: [email protected]
For additional commands, e-mail: [email protected]
