The JSON configuration can use the built-in JSON parser via the “Jason” version of the JSON configuration classes. I already added that a while ago. The Jackson ones can be moved to their own module.
As for async logging, if it’s possible to break it into its own module, that’d be great, particularly to avoid having to set a system property to enable it. — Matt Sicker > On Jun 19, 2023, at 13:24, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi all, > > While the list of optional dependencies in `log4j-core` version 3.x is > much shorter than the one in the 2.x series, we could probably still > improve it a bit: > > * we could remove `jansi`. Since Windows 10 the terminal supports > standard ANSI escapes[1]. On the other hand we broke JANSI support 3 > years ago by upgrading from JANSI 1.x to 2.x[2]: the new version does > not have the `org.fusesource.jansi.WindowsAnsiOutputStream` class we > rely upon, > * we should consider removing the Jackson dependency: > 1. it is only required by the YAML configuration format, that we > could move to a new module, > 2. the JSON configuration format should probably use the JSON > parser embedded into `log4j-api`. > * maybe we could add some POM-only artifacts like > `log4j-core-starter-async` that would depend on `log4j-core` and the > recommended version of `disruptor`. The problem I find with optional > dependencies is that consumers need to hardcode the version of the > dependency in their POM and need to remember to upgrade it when they > upgrade `log4j-core`. If we introduce "starters" for each optional > dependency (LMAX disruptor, Conversant disruptor and JCTools), users > can rely on our choice of the version. > > Piotr > > [1] https://stackoverflow.com/q/16755142/11748454 > [2] > https://github.com/apache/logging-log4j2/commit/9fabec5277f06f59ceaeff20da055ab7bf1952c4
