[
https://issues.apache.org/jira/browse/LOG4J2-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15826362#comment-15826362
]
ASF subversion and git services commented on LOG4J2-1648:
---------------------------------------------------------
Commit b886eca883699b0ba07d3ab5fc2416efdbed34bf in logging-log4j2's branch
refs/heads/master from [~mikaelstaldal]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=b886eca ]
LOG4J2-1648 ObjectThreadContextMap.putAllValues
> 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
