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 "Ralph Goers (JIRA)" <ji...@apache.org> on 2015/06/12 02:44:00 UTC
[jira] [Comment Edited] (LOG4J2-1010) Possibility to set
ThreadContext values in calls to Logger method
[ 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:43 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.
was (Author: ralph.goers@dslextreme.com):
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.
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org