I am having a difficult time locating the conversation with Ceki but it happened years ago either on the SLF4J or Logback lists. The serialization of objects in the MDC was just one issue. As I recall the larger issue related to ClassLoaders.
We don’t have problems putting objects into a ThreadLocal because we are careful about what we put there and how long it stays. In other words, we control the ThreadLocal and its contents. With the ThreadContext we control the ThreadLocal but we don’t control its contents. This means that if an application tries to shutdown any objects left in the ThreadLocal that are owned by the ClassLoader of the application will cause the undeployment of the application to fail. S I recall that is the main reason Ceki decided to only support Strings in the MDC when he created SLF4J. When I created the Log4j 2 API I couldn’t find a flaw in that reasoning. Theoretically it would be possible to support primitive objects and any objects owned by a parent ClassLoader so long as they don’t reference anything owned by the application ClassLoader, but validating that would be a nightmare. The only way I know of to support primitive objects would be to provide overloaded methods for each of the types we would want to support. Ralph > On Mar 5, 2021, at 5:57 AM, Remko Popma <[email protected]> wrote: > > 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. >>> >
