[
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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
