Just thinking that it may be worth capturing a summary of this discussion in the JIRA to make it easier to find next time. ;-)
Remko. > On Mar 6, 2021, at 3:30, Remko Popma <[email protected]> wrote: > > Ralph is spot on. I think this was the problem I remember. Web containers, > class loaders and clearing the threadlocals. > > I think there is another related JIRA about supporting primitives in the > ThreadContextMap, and I created an implementation of ThreadContextMap that > supports both Strings and primitives, but not sure if I shared the > implementation in the JIRA. > (Could be that I only have it at work.) > > >> On Mar 6, 2021, at 1:04, Ralph Goers <[email protected]> wrote: >> >> 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. >>>>> >>> >> >>
