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] [Commented] (LOG4J2-1401) Support changing the log level for all messages related to some domain object
Date Tue, 31 May 2016 14:51:12 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307838#comment-15307838

Remko Popma commented on LOG4J2-1401:

I will keep it in mind. Looks like there is at least some overlap. Not sure I'll be able to
cover everything you wanted out of LOG4J2-1010.

> Support changing the log level for all messages related to some domain object
> -----------------------------------------------------------------------------
>                 Key: LOG4J2-1401
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1401
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Core, Filters
>    Affects Versions: 2.6
>            Reporter: Remko Popma
> During system operations, it is commonly desirable to temporarily make logging for a
certain domain object more verbose. For example, all log messages related to processing a
certain order, or for a certain user, or for a certain product.
> In addition to manually increasing/decreasing verbosity, it would be nice if we can restore
the original verbosity if some condition no longer holds. For example, log at some verbose
> * for some period of time (5 minutes)
> * for some fixed number of events (10,000 log messages)
> * any other user-specified condition 
> *How to identify which log messages to log at more verbose level*
> * Marker
> * ThreadContext map
> * Other?
> Markers are cached forever, which may not be desirable if  we need to tag every log message
with the order ID, user ID and/or product ID.
> ThreadContext is a good option since values can be replaced and/or cleared so we don't
use up increasingly more memory. The drawback of the ThreadContext API is that values must
be Strings.
> We would like the ability to specify arbitrary Object values, or even primitive values.
Also, ideally this should be garbage-free (LOG4J2-1349).
> *Considerations for a new or extended ThreadContext*
> * Adding or setting values: what should the user-facing API look like?
> * Merging the snapshot of the current ThreadContext map with the Configuration Properties
into the LogEvent map
> * Getting values out of the LogEvent for use by Filters and/or Layouts. This may be by
a specified key or by iterating over the keys.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message