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] [Updated] (LOG4J2-1401) Support changing the log level for all messages related to some domain object
Date Wed, 01 Jun 2016 09:11:59 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Remko Popma updated LOG4J2-1401:
--------------------------------
    Description: 
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
level 
* for some period of time (5 minutes)
* for some fixed number of events (10,000 log messages)
* any other user-specified condition 

*Problem: How to efficiently "tag" log messages to allow more verbose logging only for relevant
log events*
Current methods available for "tagging" a log event are:
* *Markers*: String-based, name attribute only (no key-value), hierarchical (may have parents).
Current implementation caches all Markers forever, with an option to clear the whole cache.
Unclear how to use this mechanism to tag a log event with things like order ID, user ID and/or
product ID.
* *ThreadContext map*: the content of this map is put into a properties map for each Log Event.
This 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. We can also
take this opportunity to provide a garbage-free version of the ThreadContext (LOG4J2-1349).
* *Additional API* for direct user access to the Log Event properties map. (See also 
* Other possibilities are *a new MessageFactory or a new LogEventFactory*. These would require
invasive changes in the Log4j design across the board. It is not clear what the interfaces
would look like for both upstream and downstream components. Improving the other mechanisms
seems 

 Also, ideally this should be garbage-free

*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.

  was:
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
level 
* for some period of time (5 minutes)
* for some fixed number of events (10,000 log messages)
* any other user-specified condition 

*Problem: How to efficiently "tag" log messages to allow more verbose logging only for relevant
log events*
Current methods available for "tagging" a log event are:
* *Markers*: String-based, name attribute only (no key-value), hierarchical (may have parents).
Current implementation caches all Markers forever, with an option to clear the whole cache.
Unclear how to use this mechanism to tag a log event with things like order ID, user ID and/or
product ID.
* *ThreadContext map*: the content of this map is put into a properties map for each Log Event.
This 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.
* Other possibilities are *a new MessageFactory or a new LogEventFactory*. These would require
invasive changes in the Log4j design across the board. It is not clear what the interfaces
would look like for both upstream and downstream components. Improving the other mechanisms
seems 

 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.


> 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
level 
> * for some period of time (5 minutes)
> * for some fixed number of events (10,000 log messages)
> * any other user-specified condition 
> *Problem: How to efficiently "tag" log messages to allow more verbose logging only for
relevant log events*
> Current methods available for "tagging" a log event are:
> * *Markers*: String-based, name attribute only (no key-value), hierarchical (may have
parents). Current implementation caches all Markers forever, with an option to clear the whole
cache. Unclear how to use this mechanism to tag a log event with things like order ID, user
ID and/or product ID.
> * *ThreadContext map*: the content of this map is put into a properties map for each
Log Event. This 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.
We can also take this opportunity to provide a garbage-free version of the ThreadContext (LOG4J2-1349).
> * *Additional API* for direct user access to the Log Event properties map. (See also

> * Other possibilities are *a new MessageFactory or a new LogEventFactory*. These would
require invasive changes in the Log4j design across the board. It is not clear what the interfaces
would look like for both upstream and downstream components. Improving the other mechanisms
seems 
>  Also, ideally this should be garbage-free
> *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
(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