ontextMap
> ThreadContext.removeAll() method
>
>
> Key: LOG4J2-1689
> URL: https://issues.apache.org/jira/browse/LOG4J2-1689
> Project: Log4j 2
> Issue Type: Improvement
> Component
1689:
-
Commit 5b6322ae773d181a11e6633d0ec1e113f800012b in logging-log4j2's branch
refs/heads/master from [~mikaelstaldal]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=5b6322a ]
LOG4J2-1689 Rename to CleanableThreadContextMap
> ThreadContext.remove
My use case was for a ThreadContext wrapper in the Scala API:
https://issues.apache.org/jira/browse/LOG4J2-1690
On Sat, Nov 26, 2016 at 6:25 PM, Gary Gregory
wrote:
> Maybe in a unit test? But then why nit clear the whole map?
>
> Gary
>
> On Nov 26, 2016 8:09 AM, "Apache" wrote:
>
>> Do you ha
Maybe in a unit test? But then why nit clear the whole map?
Gary
On Nov 26, 2016 8:09 AM, "Apache" wrote:
> Do you have a use case for it? In all my usages of the ThreadContext I
> always add attributes one at a time but then clear the whole
> ThreadContextMap at the end of the request. It isn’
Do you have a use case for it? In all my usages of the ThreadContext I always
add attributes one at a time but then clear the whole ThreadContextMap at the
end of the request. It isn’t clear to me why someone would want to remove a
subset.
Ralph
> On Nov 10, 2016, at 5:55 AM, Mikael Ståldal w
Seems ok with me if you have a use case for it, even if it just makes tests
cleaner.
Gary
On Nov 10, 2016 4:55 AM, "Mikael Ståldal" wrote:
> Would it make sense to have a removeAll(Iterable) method in
> ThreadContext, as a companion to putAll(Map)?
>
> And a corresponding method in ThreadContex
[
https://issues.apache.org/jira/browse/LOG4J2-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal closed LOG4J2-1689.
--
> ThreadContext.removeAll() method
>
>
>
[
https://issues.apache.org/jira/browse/LOG4J2-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal resolved LOG4J2-1689.
Resolution: Fixed
Fix Version/s: 2.8
In Git master.
> ThreadContext.remove
fore next release, we can add it.
> ThreadContext.removeAll() method
>
>
> Key: LOG4J2-1689
> URL: https://issues.apache.org/jira/browse/LOG4J2-1689
> Project: Log4j 2
> Issue Type: Improvement
&
ce we might as well add whatever else rounds up the
interface. What would that be? (On my phone ATM)
> ThreadContext.removeAll() method
>
>
> Key: LOG4J2-1689
> URL: https://issues.apache.org/jira/browse/LOG4J2-1689
&
ster.
> ThreadContext.removeAll() method
>
>
> Key: LOG4J2-1689
> URL: https://issues.apache.org/jira/browse/LOG4J2-1689
> Project: Log4j 2
> Issue Type: Improvement
> Components: AP
[
https://issues.apache.org/jira/browse/LOG4J2-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15657245#comment-15657245
]
Mikael Ståldal commented on LOG4J2-1689:
Yes, done.
> ThreadContext.re
test?
> ThreadContext.removeAll() method
>
>
> Key: LOG4J2-1689
> URL: https://issues.apache.org/jira/browse/LOG4J2-1689
> Project: Log4j 2
> Issue Type: Improvement
> Components: AP
you think [~rem...@yahoo.com]?
> ThreadContext.removeAll() method
>
>
> Key: LOG4J2-1689
> URL: https://issues.apache.org/jira/browse/LOG4J2-1689
> Project: Log4j 2
> Issue Type: Improvement
&
[
https://issues.apache.org/jira/browse/LOG4J2-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal reassigned LOG4J2-1689:
--
Assignee: Mikael Ståldal
> ThreadContext.removeAll() met
Mikael Ståldal created LOG4J2-1689:
--
Summary: ThreadContext.removeAll() method
Key: LOG4J2-1689
URL: https://issues.apache.org/jira/browse/LOG4J2-1689
Project: Log4j 2
Issue Type
Would it make sense to have a removeAll(Iterable) method in
ThreadContext, as a companion to putAll(Map)?
And a corresponding method in ThreadContextMap2, which can be implemented
in an atomic way similarly to putAll.
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
17 matches
Mail list logo
