I think so yes. But a quick read doesn’t show drawbacks. Maybe I’ll remember later.
> On Mar 5, 2021, at 21:54, Volkan Yazıcı <[email protected]> wrote: > > Are you referring to LOG4J2-1648 > <https://issues.apache.org/jira/browse/LOG4J2-1648>? > >> On Fri, Mar 5, 2021 at 1:45 PM Remko Popma <[email protected]> wrote: >> >> There should be an existing JIRA that contains fairly extensive analysis >> on this topic. >> >> There are some implications/drawbacks, can’t remember off the top of my >> head. >> >> Would need to look at the ticket but no time now, maybe tomorrow. >> >>>> On Mar 5, 2021, at 19:45, Volkan Yazıcı <[email protected]> wrote: >>> >>> Hello, >>> >>> In the past couple of months I have received two complaints from people >> who >>> want to put non-String values into the ThreadContextMap. >>> ThreadContext.put*() methods only accept String values, whereas 2 of the >> 3 >>> backend maps (GarbageFreeSortedArrayThreadContextMap, >>> CopyOnWriteSortedArrayThreadContextMap) and the exposed ReadOnlyStringMap >>> interface support non-String values. (The one out of 3, >>> DefaultThreadContextMap, employed when thread locals are disabled, only >>> supports String values.) I want to improve this situation by supporting >>> Object values in ThreadContextMap. Is this a known issue? What would be >> the >>> implications of extending ThreadContextMap? I will appreciate some >> guidance >>> on this issue. >>> >>> Kind regards. >>
