You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2017/01/17 16:43:26 UTC
[jira] [Commented] (LOG4J2-1648) Provide ability for users to put
non-String values in the ThreadContext
[ 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org