Volkan,
No more hand waving. Please see
https://github.com/apache/logging-log4j2/pull/2419.
I should note that while implementing the classes I added to support this makes
it easier I did not have to make any changes to the logging internals to make
this work.
Ralph
> On Mar 22, 2024, at 1:45 AM, Volkan Yazıcı wrote:
>
> No, it is not the same thing Matt. Let me be as explicit as I can:
>
> var logger0 = getLogger(); // MDC: {}
> var logger1 = logger0.withContextData("x", 1); // MDC: {x: 1}
> var logger2 = logger1.withContextData("y", 2); // MDC: {x: 1, y: 2}
>
> This is the functionality being requested. Whoever claims this can be done
> using a `MessageFactory`, they need to share a working [pseudo] code, instead
> of hand waving. So far, nobody responded to this. Piotr, speculated on a
> non-existing `Logger#withMessageFactory(MessageFactory)`, but there is not
> one single working example shared. Hence, unless you can prove me wrong with
> a working practical[1] example, the requested feature is currently known to
> be not practically possible in Log4j.
>
> [1] Implementing `logger.withContextData("x", 1)` with 50 LoC Java code using
> the existing Log4j feature set is not a "practical example".
>
> P.S. For Log4j 3 API Javadocs, you can browse to
> https://logging.apache.org/log4j/3.x and search for "Javadoc" in the menu.
> (Obviously, same works for Log4j 2 too.)
>
> On Thu, Mar 21, 2024 at 6:10 PM Matt Sicker wrote:
> LogManager - log4j-api 3.0.0-alpha1 javadoc
> javadoc.io
>
> Pass your custom MessageFactory here. It’s an optional argument when creating
> the Logger.
>
> Also, I’m not sure where to even find the current javadocs for the API.
> javadoc.io only seems to have this alpha release.
>
>
>> On Mar 21, 2024, at 04:34, Volkan Yazıcı wrote:
>>
>> Ralph, could you show how those two users can use a `MessageFactory` to
>> create `Logger`s with predefined additional context data?
>>
>> On Thu, Mar 21, 2024 at 7:25 AM Ralph Goers wrote:
>>
>>> Unfortunately this is another message I somehow didn't get in my inbox.
>>> Replying to it via lists.a.o is not a great experience but is the best I
>>> can do.
>>>
>>> On 2024/03/20 13:51:56 Volkan Yazıcı wrote:
I agree with the way Piotr dissects the problem. I think `ScopedContext`,
even though it has its own merits, doesn't address the problem reported
>>> by
users. They simply want a new logger associated with some additional
context data.
>>>
>>> Two users do. I have personally been asked for something like
>>> ScopedContext several times.
>>> As I replied to Piotr, we already solved the problem of adding data to
>>> Loggers. That is what MessageFactories are intended for.
>>>
*[See my comments below.]*
On Mon, Mar 18, 2024 at 10:40 AM Piotr P. Karwasz <
>>> piotr.karw...@gmail.com>
wrote:
> * we can create a `Logger` wrapper "bound" to context data as Mikko
> does. This wrapper will take care of setting the `ThreadContext`
> before the logger call and restore it after it.
Creating a wrapper `Logger` can work without needing to deal with
`ThreadContext`. I can think of two different ways to carry this out:
1. Currently, `AbstractLogger` only creates `Message`s. We can rework
>>> it
to create `LogEvent`s too. Once `AbstractLogger` gets its hand on a
`LogEvent`, it can enrich its context data as it wishes.
2. We can extend `ContextDataInjector` with a new `void
injectContextData(Logger logger, StringMap target)` method, provide a
`ContextDataInjector` implementation that branches on `logger
>>> instanceof
ContextDataProvider`, and call `ContextDataInjector` with the
>>> associated
`Logger` in `LogEventFactory`.
>>>
>>> We can do lots of things, most of which I wouldn't recommend. As to yours:
>>> 1. Logger/AbstractLogger got very complex with Async, Garbage Free,
>>> Reliablity Strategies, etc. Trying to move creating the LogEvent sooner is
>>> likely to be a major PITA and could seriously impact performance. While we
>>> could add a context map to AbstractLogger we would have to pass that on the
>>> logging calls to LoggerConfig and deal with all that that means - remember,
>>> a LoggerConfig can be handling multiple Loggers.
>>> 2. I don't recommend extending ContextDataInjector. That proved difficult
>>> to work with which is why we now recommend using ContextDataProviders. You
>>> really can only have one ContextDataInjector. Also, please note that
>>> ContextDataInjector is called while constructing the LogEvent. The LogEvent
>>> isn't passed the Logger, only the LoggerName. Looking up the Logger to do
>>> this is yet another way to slow down logging.
>>>
On Tue, Mar 19, 2024 at 7:45 AM Ralph Goers
wrote:
> In the meantime, I provided
https://github.com/apache/logging-log4j2/pull/2385 which I very loosely
modeled after ScopedValues.
>
