[log4j] Question about the initial configuration created in LoggerContext
So I’m working on the properties enhancement issue, and one thing I’ve come across to clean up are the situations where the LoggerContext may be null in the constructor to AbstractConfiguration. Previously, this only seemed to be the case for NullConfiguration, but it may also apply to DefaultConfiguration during startup. However, suppose I construct a LoggerContext with a configuration location corresponding to a file (so the only supported file path type via that constructor). This location does not get used until the LoggerContext starts; before this, it constructs a DefaultConfiguration. During this bootstrapping, if the configuration location is available (such as for a unit test), should LoggerContext set up the configuration provided? Or is there some sort of cyclic dependency here preventing us from loading ConfigurationFactory right away? So far, the only cyclic dependencies I’ve found are related to plugins created in the DefaultConfiguration (or the NullConfiguration in some cases), but those are already commented as such (like in PatternLayout). I’ll note for reference that LoggerContext has two families of constructors that fan out into the following parameters: String name, Object externalContext, String/URI configLocation, Injector injector, PropertyResolver propertyResolver -> LoggerContext The external context concept here seems to mainly be used for passing along a ClassLoader instance or something derived from it (I think a Bundle does or something from OSGi at least). These constructors do call Injector::init, so the point of providing an Injector instance here would be if you preconfigured some beans (like in a unit test) before wanting to load the default bundles of beans/bindings. — Matt Sicker
Re: Binding `log4j-slf4j2-impl` to `log4j-core`
Hi Volkan, On Sat, 17 Dec 2022 at 19:50, Volkan Yazıcı 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
