[
https://issues.apache.org/jira/browse/LOG4J2-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601679#comment-15601679
]
Mikael Ståldal commented on LOG4J2-1648:
----------------------------------------
It is possible to insert non-String entries in the context data by using a
custom ContextDataInjector. But you shouldn't have to do that if you want to
keep the ThreadContext semantics otherwise.
> Provide ability for users to put 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
>
> 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
(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
