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 <m...@musigma.org> wrote: > LogManager - log4j-api 3.0.0-alpha1 javadoc > <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html> > javadoc.io > <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html> > [image: fb2db6ea7688d54ae047109e0d71e3a0-favicon-32.png] > <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html> > <https://www.javadoc.io/doc/org.apache.logging.log4j/log4j-api/3.0.0-alpha1/org.apache.logging.log4j/org/apache/logging/log4j/LogManager.html> > > 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ı <vol...@yazi.ci> 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 <rgo...@apache.org> 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 <ralph.go...@dslextreme.com> > wrote: > > In the meantime, I provided > > https://github.com/apache/logging-log4j2/pull/2385 which I very loosely > modeled after ScopedValues. > > The fact that `ScopedContext` tries to imitate `ScopedValue` using > `ThreadLocal`s is extremely confusing (from a user's pov) and risky > liability (from a maintainer's pov). I guess you wanted to implement *a* > `ScopedValue` without using *the* `ScopedValue` to be compatible with > > Java > > 8. If so, that really sounds like the `o.a.l.log4j.util.Supplier` > > downward > > spiral. We can rather have an *internal* `Log4jScopedValue` interface and > provide Java 8 (using `InheritableThreadLocal`) and Java 21+ (using > `ScopedValue`) compatible solutions in an MRJ (Multi-Release JAR). > > > I am NOT trying to make ScopedContext compatible with ScopedValue. I am > trying to make it conceptually close enough to ScopedValue that users will > understand what it is doing. > We can argue about naming if you want. Gary has already expressed his > opinion. > > > We can integrate `ScopedContext` to the `LogEventFactory` by providing a > specialized `ContextDataInjector` plugin – assuming `LogEventFactory` > employs all available `ContextDataInjector` plugins. > > > ScopedContext is integrated with a ContextDataProvider, which is the > supported way to do this. Again, you cannot have more than one > ContextDataInjector so providing "specialized versions" is a pipe dream. > You will simply have to enhance the one we already have. > ContextDataInjector is NOT a plugin. > > > I find the current ceremony also too long: > `ScopedContext.getCurrent().where("key1", "value1").run(...)`. I would > rather aim for `ScopedContext.run(key, value, runnable)` and similar > `ScopedContext.op(..., runnable)` interaction. > > > Those are going to be provided as well. > > Ralph > > >