[
https://issues.apache.org/jira/browse/LOG4J2-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15326312#comment-15326312
]
Remko Popma edited comment on LOG4J2-1401 at 6/12/16 10:39 AM:
---------------------------------------------------------------
Similarly to LOG4J2-1424, one way to approach this is to replace the log event
's Map<String, String > attribute with a more general LogEventProperties
interface. Users can control the implementation by configuring a factory.
The LogEvent interface would need an additional method
{{getLogEventProperties()}} so downstream components like Filters and Layouts
can be implemented on custom LogEventProperties implementations.
This LogEventProperties interface would have an {{update()}} method called
when the log event is initialized and a {{clear()}} method for reuse in
garbage-free scenarios. It would also need an {{asMap()}} method to implement
LogEvent#getContextMap().
A DefaultLogEventProperties implementation copies key/values from the
ThreadContext (merged with Configuration properties). A custom implementation
could get values from a custom ThreadContext-like data structure.
This interface will allow us to store arbitrary data from arbitrary sources in
LogEvents.
was (Author: [email protected]):
Similarly to LOG4J2-1424, one way to approach this is to replace the log event
's Map<String, String > attribute with a more general LogEventProperties
interface. Users can control the implementation by configuring a factory.
The LogEvent interface would need an additional method
{{getLogEventProperties()}} so downstream components like Filters and Layouts
can be implemented on custom LogEventProperties implementations.
This LogEventProperties interface would have an {{update()}} method called
when the log event is initialized and a {{clear()}} method for reuse in
garbage-free scenarios. It would also need an {{asMap()}} method to implement
LogEvent#getProperties().
A DefaultLogEventProperties implementation copies key/values from the
ThreadContext (merged with Configuration properties). A custom implementation
could get values from a custom ThreadContext-like data structure.
This interface will allow us to store arbitrary data from arbitrary sources in
LogEvents.
> 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 1: Log Event "Tagging"*
> How to efficiently "tag" log messages to select only _some_ log events to be
> output at a more verbose level but don't show _all_ 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.
> ** Update: one way to address these issues is to create a KeyValueMarker
> implementation of the Marker interface. A single instance could contain
> multiple tags (key-value pairs of arbitrary type). Instances cannot be
> cached by name in the MarkerManager, but instead I imagine we can use a pool
> of KeyValueMarkers to reuse (so we would need to call release() or something
> when the log event is fully processed).
> * *ThreadContext map*: the content of this map is merged into a properties
> map for each Log Event. 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) and the
> LogEvent properties map.
> * *Direct user access to the LogEvent properties map*. LOG4J2-1010 suggests
> changing the Logger API to accomplish this, but there may be alternatives
> (needs more thought). Similar to the above, ideally we would like the ability
> to specify arbitrary Object values, or even primitive values, not just
> Strings.
> * 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 a better option.
> *Problem 2: Dynamic filtering*
> * What mechanism to use for increasing verbosity of events matching some
> condition? Global filters (on LogEvent properties or markers) may be a good
> candidate.
> * How can operators enable/disable this on the fly?
> * How can we provide convenience features for automatically reverting to the
> previous level of verbosity when some condition is met (e.g. after 10,000
> events or after 5 minutes etc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
