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-1447) Garbage-free data structure for LogEvent's context map data
Date Fri, 29 Jul 2016 00:08:20 GMT

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

Remko Popma commented on LOG4J2-1447:

It gives client code the choice to either receive an Object or receive a more specific type.
With {{getValue}}, the client code may know what type to expect for a certain key. With {{forEach(TriConsumer,
T)}}, the second parameter is an object the client passes in so the compiler knows the type.
Admittedly, if you put values of multiple different types in the ContextData, you cannot benefit
from an iterator with a generic value type, and you would have to use Object. All these use
cases are supported with the current code.

> Garbage-free data structure for LogEvent's context map data
> -----------------------------------------------------------
>                 Key: LOG4J2-1447
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1447
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.6.1
>            Reporter: Remko Popma
>            Assignee: Remko Popma
>             Fix For: 2.7
> With each logging call, context map data is copied from the {{ThreadContext}} map into
the {{LogEvent}}.
> The LogEvent interface exposes this data via the {{getContextMap() : Map<String, String>}}
method, and this is implementated by storing the data in a Map<String, String>.  The
JDK Map is not an easy data structure to make garbage-free. It would also be nice to have
the ability in LogEvent to carry data of any type.
> One idea is to introduce a small interface that is general enough to be map-like but
can be implemented in a garbage-free manner. 
> LogEvent implementations would have an instance of this interface instead of the current
{{java.util.Map<String, String> contextMap}} attribute.
> The interface could look something like this:
> {code}
> interface ContextData<String, V> {
>     /** Called to implement {@link LogEvent#getContextMap()}. */
>     Map<String, String> asMap();
>     /** Put key-value pair into the table.
>         Remove key if value is null. */
>     void put(String key, V value);
>     /** Returns the value for the specified key. */
>     V getValue(String key);
>     /** Number of key-value pairs. */
>     int size();
>     /** Removes all key-value pairs. */
>     void clear();
> // Instead of Iterators, client code provides the consumer.
>     /** 
>      * Performs the given action for each key-value pair in this data structure
>      * until all entries have been processed or the action throws an exception.
>      */
>     void forEach(BiConsumer<String, ? super V> action);
> }
> /**
>  * An operation that accepts two input arguments and returns no result.
>  */
> interface BiConsumer<T,U> {
>     /** Performs the operation given the specified arguments. */
>     void accept(T t, U u);
> }
> {code}
> The LogEvent interface would have an additional method {{getContextData() : ContextData<K,
V>}} that gives downstream components direct access to the new data structure. 
> Existing downstream components would still be able to call {{logEvent.getContextMap()}}
to get a {{Map<String, String>}} view of the context map data and this would work as

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