[jira] [Reopened] (LOG4J2-1516) Add ThreadContextMap.putAll(Map)

["Remko Popma (JIRA)" <ji...@apache.org>]

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

Remko Popma reopened LOG4J2-1516:
---------------------------------

Sorry for the delay in taking a look at this.

The main problem I have with this is that {{ThreadContextMap}} is in the SPI package of our API module. Generally binary compatibility is important, but for our extension points we should be doubly careful. Adding a new method to this interface would break custom user implementations.

If we really need this method I propose we create a {{ThreadContextMap2 extends ThreadContextMap}} interface, similar to what we did with MessageFactory.

I have no problem adding a static {{putAll}} method to the {{ThreadContext}} facade (LOG4J2-1519). This can then be implemented by looping over the specified Map and putting the entries one by one, or, if the underlying ThreadContextMap implements ThreadContextMap2, invoke the putAll method as an optimization.

> Add ThreadContextMap.putAll(Map<String, String>)
> ------------------------------------------------
>
>                 Key: LOG4J2-1516
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1516
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: API
>            Reporter: Gary Gregory
>            Assignee: Gary Gregory
>             Fix For: 2.7
>
>
> Add API {{ThreadContextMap.putAll(Map<String, String>)}}.
> My immediate goal is to be able to build a JUnit Rule to save and restore the thread context around each unit test method and/or a given class.
> See [LOG4J2-1517].



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