On Sat, May 25, 2024, at 04:22, Gary Gregory wrote:
> I'd like to have the PMC meet to review and discuss ScopedContext,
> which I am not caught up on, and whatever else we should chat about.
Me too.
I feel that all the discussion on the ScopedContext should be in an
experimental branch or an additional jar file rather than the stable code base.
I see it popping up so often, I start to believe it's "not there yet."
Christian
>
> Gary
>
> On Fri, May 24, 2024 at 2:11 PM Piotr P. Karwasz
> <piotr.karw...@gmail.com> wrote:
>>
>> Hi John,
>>
>> On Fri, 24 May 2024 at 17:17, John Engebretson <jengebr...@gmail.com> wrote:
>> > The long-debated ScopedContext is not significant to us. Can
>> > we set a target date for 2.24.0? Perhaps by punting ScopedContext to a
>> > later date?
>>
>> +1, the release of 2.24.0 is a blocker for:
>>
>> * the release of a performance-optimized and web-app safe
>> `ThreadContextMap` you contributed more than 2 months ago[1],
>> * the release of the next 3.0.0 beta, which will be the first without
>> a `log4j-api` artifact,
>> * a Log4j API without the LambdaMetaFactory call that makes versions
>> 2.19.0 to 2.23.1 unsuitable for GraalVM.
>>
>> Probably by the beginning of June (after CoCEU 2024) I can:
>>
>> 1. Move `ScopedContext` to branch 2.25.x,
>> 2. Replace `DefaultThreadContextMap` with the new
>> `StringArrayThreadContextMap`,
>> 3. Check if `StringArrayThreadContextMap` allows for "garbage-free
>> logging" (if it doesn't, it must be very close) and remove
>> `CopyOnWriteThreadContextMap`,
>>
>> So realistically we could expect 2.24.0 by the end of June.
>>
>> I believe that ScopedContext is a valid idea, but it still requires
>> some massaging. I haven't seen any performance figures yet and if the
>> main selling point is "you can't forget to clean up the thread
>> context", I am not too convinced of its utility. ThreadContext and MDC
>> have been around for a long time and people know how to use them
>> correctly.
>>
>> We should probably:
>>
>> * have a PMC meeting to brainstorm on all the selling points of
>> `ScopedContext`,
>> * do some benchmarks to see its performance,
>> * review all its methods so we don't repeat the errors of the past. As
>> I stated several times, 'ThreadContext.get()` is a mistake, because it
>> allows users to abuse the API and transport logging-unrelated data
>> through `ThreadContext`. If we could correct the past, I would remove
>> `ThreadContext.get()` and let `ThreadContext.put()` return the old
>> value.
>>
>> Piotr
>>
>> [1] https://github.com/apache/logging-log4j2/pull/2330
