[
https://issues.apache.org/jira/browse/LOG4J2-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15827959#comment-15827959
]
Remko Popma commented on LOG4J2-1648:
-------------------------------------
To answer Mikael's question on the mailing list:
What is left on this ticket is analysis and discussion on whether we want to
add more API. I currently don't have the time or energy to do that work, but
I'd like to keep the ticket open.
Some work was done: the ObjectThreadContextMap SPI interface was added and is
implementated by several ThreadContextMap implementations. This, in combination
with LOG4J2-1660 allows users to accomplish the desired functionality with a
custom facade (to be used instead of ThreadContext). I'm not sure if that has
been documented.
One idea is to deliberately leave this undocumented for now until we are
decided on what direction to take this item. If we're ok with that then there's
no further work required for the 2.8 release.
> 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
