Hi all, On Sat, 16 Apr 2022 at 00:17, Carter Kozak <cko...@ckozak.net> wrote: > I can understand how the stack-based mdc might be convenient and useful, but > I don't think it fits my use-cases. That said, I wonder if the API could be > improved in such a way that it could leverage the application stack instead > of maintaining its own -- this is an issue that I've encountered in tracing > implementations as well, where asymmetric interactions to cause the > application stack and internal stack to get out of sync. Perhaps using > something like putCloseable[1] would allow the data needed to reset to be > stored in the closeable without maintaining a standalone stack (at the cost > of the ability to support getCopyOfDequeByKey[2]).
Since Ceki announced the release of SLF4J 2.0.0, the topic is back. We need to decide whether: 1. we extend the Log4j2 API to support the "enhanced" NDC version of SLF4J2, 2. we use the default implementation provided by Ceki, 3. we hack around it (e.g. encoding a list of values to a JSON-like structure) like in https://github.com/apache/logging-log4j2/pull/820. I would use Ceki's implementation and provide a `PatternConverter` for those hordes of users that will use it. Alternatively we could inject the top values from Ceki's NDC into the usual ThreadContextMap. What do you think?
