I don’t think that’s the only sane option. Another sane option is to ignore it.
There’s nothing that says Log4j has to implement any enhanced SLF4J APIs. He wants to be the lowest common denominator in logging APIs, then he can’t add APIs that aren’t supported in the major implementations. Just throw an UnsupportedOperationException. > On Aug 23, 2022, at 2:04, Ralph Goers <[email protected]> wrote: > > It would be weird IMO to provide a PatternConverter for an NDC stack that is > supported by SLF4J but not Log4j. > > Unfortunately, I think the only sane thing to do is option 1. > > Ralph > >> On Aug 22, 2022, at 8:45 AM, Piotr P. Karwasz <[email protected]> >> wrote: >> >> Hi all, >> >>> On Sat, 16 Apr 2022 at 00:17, Carter Kozak <[email protected]> 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? >
