[jira] [Comment Edited] (LOG4J2-1447) Garbage-free data structure for LogEvent's context map data

["Ralph Goers (JIRA)" <ji...@apache.org>]

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

Ralph Goers edited comment on LOG4J2-1447 at 7/9/16 7:49 AM:
-------------------------------------------------------------

The only issue I have is with the put and clear methods. If the data structure is immutable the interface exposed to Filters, Appenders, etc shouldn't allow modification. Of course, the actual implementation class can have a put method or whatever is needed to populate the data structure.


was (Author: ralph.goers@dslextreme.com):
The only issue I have is with the put method. If the data structure is immutable the interface exposed to Filters, Appenders, etc shouldn't allow modification. Of course, the actual implementation class can have a put method or whatever is needed to populate the data structure.

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



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