Hi Volkan, On Sat, 17 Dec 2022 at 19:50, Volkan Yazıcı <vol...@yazi.ci> wrote: > 2. Regarding removing the `log4j-core` dependency from > `log4j-slf4j[2]-impl` artifacts in `master`... I see where you are > coming from and I agree this is _technically_ the right approach. That > said, comments in LOG4J2-3601 clearly indicate that it is not > intuitive for users. Put another way, users clearly indicate this was > unexpected for them. I also think this is due to the fact that users > still think _Log4j API is Log4j_, which is not true. I am inclined to > gravitate from _the technically right approach_ to _the intuitive > approach_: having `log4j-core` as a runtime dependency for > `log4j-slf4j[2]-impl` artifacts. For one, this is what users ask for. > Second, it implicitly onboards Log4j, which is good for us. Third, > users can still opt-out via exclusion, if needed.
My problem with the "intuitive approach" is that it confirms the misconception many people have about Log4j2 API: they consider Log4j2 API as the internal API of Log4j2 Core (cf. PAX logging Github page[1] for an example), nothing more. The State of the Art in Java logging seems to be SLF4J + Log4j2 Core. Due to the great amount of old documentation, that is what I thought too, when I first started playing with logging frameworks. No one is surprised that `log4j-to-slf4j` does *not* have a dependency on `logback-classic`, but many users are surprised if `log4j-slf4j2-impl` does not have a dependency on `log4j-core`. Changing the dependencies of `log4j-slf4j2-impl` in 3.x might be a step in the right direction, although we might first document why SLF4J is not the right choice if you choose Log4j2 Core as default backend. Piotr [1] https://github.com/ops4j/org.ops4j.pax.logging
