+1 for removal of `jansi` +1 for moving the YAML configuration support to a separate module
+1 for using `JsonReader` in API for reading the JSON configuration +1 for `log4j-core-starter-async` (Shouldn't it rather be called `log4j-core-async-starter` according to Spring Boot starter naming conventions?) On Mon, Jun 19, 2023 at 1:25 PM 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 >
