Hi Ralph, On Tue, 23 Aug 2022 at 08:14, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I don’t see that as a problem at all. Log4jLogEvent’s constructor accepts a > List of properties. We use this to inject properties configured on Loggers > into the Context Map of the LogEvent. I see no reason why these key/value > pairs shouldn’t be treated the same way.
Thanks, I didn't know about this feature. I didn't find a way of passing a list of properties from a logger to a Log4jLogEvent without extending the `Logger` interface, so I used a simple `CloseableThreadContext#putAll` to inject the values in the context map[1]. Regarding the "enhanced" MDC feature in SLF4J I am more and more convinced that SLF4J's `pushByKey` is the equivalent of `CloseableThreadContext#put` and `popByKey` is the equivalent of closing a `CloseableThreadContext.Instance`. Ceki's `MDC.putCloseable` does not restore the original value upon closure, which is probably the reason he "enhanced" the MDC interface. Anyway I think that either Pierrick's [2] or mine [3] attempt to implement the "enhanced" MDC should solve the problem. This would leave us with the question whether to implement `LoggingEventAware` or not and we fully support SLF4J 2.0. I am not entirely sure if we should allow users to create entire logging events. Piotr [1] https://github.com/apache/logging-log4j2/pull/1024 [2] https://github.com/apache/logging-log4j2/pull/1022 [3] https://github.com/apache/logging-log4j2/pull/1025
