[
https://issues.apache.org/jira/browse/LOG4J2-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842113#comment-17842113
]
Ralph Goers commented on LOG4J2-1648:
-------------------------------------
I added ScopedContext to the Log4j API and it should be included in 2.24.0.
This allows Objects to be added and due to how a ScopedContext has to be used
it should always be safe.
> Allow non-String values in the ThreadContext
> --------------------------------------------
>
> Key: LOG4J2-1648
> URL: https://issues.apache.org/jira/browse/LOG4J2-1648
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.7
> Reporter: Remko Popma
> Priority: Major
>
> I would like to discuss possibilities for an API that allows users to put
> Object values in the ThreadContext.
> Since 2.7, LogEvents can hold non-String values in their context data, but
> the Log4j API only allows users to put String values in the ThreadContext.
> Not all ThreadContextMap implementations support Object values. For example,
> the default ThreadContextMap implementation only allows Strings, to prevent
> memory leaks in web apps.
> Users need to configure Log4j to use one of the StringMap-based
> ThreadContextMap implementations, but even if they do so there is currently
> no API that allows them to actually use this and put arbitrary Objects in the
> thread context... How can we make this available?
> Some ideas:
> # Add methods to the ThreadContext facade that allow getting and putting
> Object values, and getting a read-only copy of the StringMap. These methods
> throw an UnsupportedOperationException if the underlying ThreadContextMap
> implementation does not support the operation. There should also be a method
> that returns a boolean signifying whether the implementation supports Object
> values.
> # Add a separate facade class, say, ObjectThreadContext that provides these
> methods
> # Other?
> Without such an API, there is no clean alternative for users to achieve this.
> There is also no extension point that would allow them to leverage existing
> Log4j code when they build something custom for this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
