[
https://issues.apache.org/jira/browse/LOG4J2-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582739#comment-14582739
]
Ralph Goers edited comment on LOG4J2-1010 at 6/12/15 12:53 AM:
---------------------------------------------------------------
I would encourage you to look at the log method in LoggerConfig at line 352. If
you notice, it gathers properties from the LoggerConfig and adds them to the
LogEvent. These properties end up being included in the ThreadContext in the
LogEvent. Also, these properties are interpolated every time a log event is
created. So you could create your own lookup and have it populate a property
with all the items you want included in the log event. All of this will work
with no changes to Log4j. You would just need to declare the properties in your
log4j2.xml.
If, for some reason, that isn't sufficient for you we could add another type of
MapMessage that would have the properties in the Map included as properties in
this log method.
I should also point out that some of the layouts already inspect the type of
Message being processed and handle it in a way that makes sense. For example,
the MessagePatternConverter, which is used by the PatternLayout, calls a
special version of getFormattedMessage that accepts a format string if the
message is a MultiFormattedMessage (which a MapMessage is). So if you use a
MapMessage and the standard PatternLayout the members of your Map would
automatically be printed. Of course you could extend MapMessage to implement
your own version of getFormattedMessage.
was (Author: [email protected]):
I would encourage you to look at the log method in LoggerConfig at line 352. If
you notice, it gathers properties from the LoggerConfig and adds them to the
LogEvent. These properties end up being included in the ThreadContext in the
LogEvent. Also, these properties are interpolated every time a log event is
created. So you could create your own lookup and have it populate a property
with all the items you want included in the log event. All of this will work
with no changes to Log4j. You would just need to declare the properties in your
log4j2.xml.
If, for some reason, that isn't sufficient for you we could add another type of
MapMessage that would have the properties in the Map included as properties in
this log method.
I should also point out that some of the layouts already inspect the type of
Message being processed and handle it in a way that makes sense. For example,
the MessagePatternConverter, which is used by the PatternLayout, calls a
special version of getFormattedMessage that accepts a format string if the
message is a MultiFormattedMessage (which a MapMessage is). So if you use a
MapMessage and the standard PatternLayout the members of your Map would
automatically be printed.
> 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
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
