Re: Putting non-String values into ThreadContextMap

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 wrote: > > Ralph is spot on. I think this was the problem I remember. Web containers, > class loaders and clearing the

Re: Putting non-String values into ThreadContextMap

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

Re: Putting non-String values into ThreadContextMap

Yes, we could allow primitive types and collections of primitive types. But the only ways I know to do that would be a) created overloaded methods for every supported type or b) check at runtime and reject any unsupported type. Option a will seriously bloat the interface and option b seems unten

Re: Putting non-String values into ThreadContextMap

What about only allowing primitive types and standard containers, i.e., map and collection? We can easily validate that as we do while serializing JSON. On Fri, 5 Mar 2021, 17:55 Ralph Goers wrote: > That is the same as remove(). > > Think about how Tomcat works. It creates a Thread pool for all

Re: Putting non-String values into ThreadContextMap

That is the same as remove(). Think about how Tomcat works. It creates a Thread pool for all incoming requests. They are no threads dedicated to a single application. Applications are supposed to clear any ThreadLocals when the execution on a Thread ends otherwise the values will be there whe

Re: Putting non-String values into ThreadContextMap

What about simply calling threadLocal.set(null) at shutdown? On Fri, 5 Mar 2021, 17:30 Ralph Goers wrote: > The remove() method would have to be called on every thread. Setting the > ThreadLocal to null will cause massive problems if Log4j is installed in > the parent’s ClassLoader as you would

Re: Putting non-String values into ThreadContextMap

The remove() method would have to be called on every thread. Setting the ThreadLocal to null will cause massive problems if Log4j is installed in the parent’s ClassLoader as you would be killing the ThreadLocal for all applications, not just the one being underplayed. ClassLoaders are fun. Ral

Re: Putting non-String values into ThreadContextMap

There's a remove() method on ThreadLocal. On Fri, 5 Mar 2021 at 10:13, Volkan Yazıcı wrote: > > 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 > wrote: > > > I am having a difficult time locating the conversat

Re: Putting non-String values into ThreadContextMap

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 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 objec

Re: changes.xml

I have copied the 2.14.1 of changes.xml from release-2.x to master and I have removed the duplicates in the 3.0.0. Note that the 3.0.0 block in master still needs to be grouped into fixes, updates, etc. sections. I will do that grouping if you are okay with the previous change. On Fri, Mar 5, 2021

Re: Putting non-String values into ThreadContextMap

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 Threa

Re: changes.xml

Please move the actions you added. Some of them may legitimately apply to 3.0.0 and it would be tedious for me to verify each one. Ralph > On Mar 5, 2021, at 8:39 AM, Volkan Yazıcı wrote: > > 🤦‍♂️ I am in that group of people. > Thanks for the warning and sorry for the mess. > Are you gonna ti

Re: changes.xml

🤦‍♂️ I am in that group of people. Thanks for the warning and sorry for the mess. Are you gonna tidy it up or shall I give it a try? On Fri, Mar 5, 2021 at 7:23 AM Ralph Goers wrote: > Looking at changes.xml it looks like actions that are being fixed in > 2.14.1 in the release-2.x branch and 3.

Re: LOG4J2-3033 LogBuilder don't require a message

I didn’t realize the requester had created a Jira issue. I fixed LOG4J2-2947 last night and included the log() method as I remembered seeing the request. So I guess I just need to add this issue to changes.xml. Ralph > On Mar 5, 2021, at 8:18 AM, Volkan Yazıcı wrote: > > This sounds like a le

LOG4J2-3033 LogBuilder don't require a message

This sounds like a legit request to me. Isn't it just a matter of introducing a LogBuilder#log() method to the interface and implementing it? If it is that simple, I can give it a shot. -- Forwarded message - From: Caleb Cushing (Jira) Date: Mon, Mar 1, 2021 at 7:23 PM Subject: [j

Re: Putting non-String values into ThreadContextMap

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ı wrote: > > Are you referring to LOG4J2-1648 > ? > >> On Fri, Mar 5, 2021 at 1:45 PM Remko Popma wrote: >> >> Th

Re: Putting non-String values into ThreadContextMap

Are you referring to LOG4J2-1648 ? On Fri, Mar 5, 2021 at 1:45 PM Remko Popma 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 to

Re: Putting non-String values into ThreadContextMap

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ı wrote: > > Hell

Putting non-String values into ThreadContextMap

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, CopyOnWriteSortedArrayThreadC