[
https://issues.apache.org/jira/browse/LOG4J2-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15604984#comment-15604984
]
Remko Popma commented on LOG4J2-1648:
-------------------------------------
Understood that there are usages for which this feature is not appropriate. Web
applications is one example, SerializedLayout is another. But I would not want
to rule this out because it is not appropriate for some users.
Even if we don't provide API to allow end users to put objects in the thread
context directly, we should at least provide an extension point that would
allow users to build something custom.
*Extension point*
The extension point I have in mind would be one new SPI interface with get and
put methods for Object values. Our existing StringMap-based ThreadContextMap
implementations would implement this new interface.
{code}
package org.apache.logging.log4j.spi;
public interface ThreadContextMap3 extends ThreadContextMap2 { // new interface
Object getValue(String key);
void putValue(String key, Object value);
}
{code}
{code}
package org.apache.logging.log4j.spi;
// existing StringMap-based implementations of ThreadContextMap would implement
the new ThreadContextMap3 interface
class CopyOnWriteSortedArrayThreadContextMap implements ThreadContextMap3,
CopyOnWrite { ... }
class GarbageFreeSortedArrayThreadContextMap implements ThreadContextMap3 {
... }
{code}
*End user API*
We can provide only the extension point and let users create classes like the
below as custom extensions, or we can provide the below class as part of the
log4j API, with the caveats that web applications should not use this class (at
least until LOG4J2-1116 is addressed), and the Objects you put here need to be
Serializable if you use the SerializedLayout.
{code}
package org.apache.logging.log4j;
public class ObjectThreadContext {
public static boolean isSupported() {
return ThreadContext.getThreadContextMap() instanceof ThreadContextMap3;
}
public static Object getValue(String key) {
return getObjectMap().getValue(key);
}
public static void putValue(String key, Object value) {
getObjectMap().putValue(key, value);
}
private static ThreadContextMap3 getObjectMap() {
if (!isSupported()) { throw new UnsupportedOperationException(); }
return (ThreadContextMap3) ThreadContext.getThreadContextMap();
}
}
{code}
> 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
