[ 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 expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org