Maybe thinking naively but... Can't we just set the ThreadLocal to null at shutdown?
On Fri, Mar 5, 2021 at 5:04 PM 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. > >>> > > > > >
