I agree with your remark on priority. Using Log4j 2 API in Log4j 3 is indeed our focus. My recent refactoring of `StatusLogger` was a part of that effort. Since I already have my hands dirty with it, I want to take one last step to polish it in `main` and remove the `StatusConfiguration` wrinkle.
As soon as I have time, I will land two PRs: 1. One against `2.x` to warn that `StatusConfiguration` will be removed 2. One against `main` to remove the `StatusConfiguration` I also agree that having `StatusLogger` per `LoggerContext` is an overkill and I am strongly opinionated on that. On Wed, Feb 14, 2024 at 4:34 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > There could be if there was a StatusLogger per LoggerContext. But you > would still need a global StatusLogger. But doing that seems like overkill. > > On the one hand it is very convenient to configure the level in the config > file, but on the other the fact that it only takes place halfway through > configuration is a bit of a problem as that is largely when it is needed. > > There is also the issue of compatibility. If support for it is removed we > would still need to tolerate its presence. In the beginning we could log an > Info message and then after a while convert it to a warn message before > support is removed. > > To be honest, this isn’t a top priority on the list of things that need to > be addressed for me which is partly why I guess I am hesitant to do > anything. It feels like we keep talk about making changes but aren’t really > focused on getting 3.0 done. Of course, deciding to stick with the 2.x API > threw a wrinkle into the works of getting 3.x out the door but I’d still > like that to be our top focus. > > Ralph > > > On Feb 13, 2024, at 10:21 AM, Matt Sicker <m...@musigma.org> wrote: > > > > If there were a way to allow for multiple StatusLogger configurations > concurrently, then I’d support keeping it in the config file. Otherwise, > I’m somewhat ambivalent about this. > > > >> On Feb 12, 2024, at 13:29, Volkan Yazıcı <vol...@yazi.ci> wrote: > >> > >> *Abstract:* I want to remove from `main` the feature that a > `Configuration` > >> (e.g., `<Configuration status="WARN" dest="out">` in a `log4j2.xml`) > >> configuring the `StatusLogger`, and instead, only allow configuration > using > >> properties. > >> > >> `StatusLogger` can be configured in following ways: > >> > >> 1. Passing system properties to the Java process (e.g., > >> `-Dlog4j2.StatusLogger.level=INFO`) > >> 2. Providing properties in a `log4j2.StatusLogger.properties` file in > >> the classpath > >> 3. Using Log4j configuration (i.e., `<Configuration status="WARN" > >> dest="out">`) in a `log4j2.xml` in the classpath. This is facilitated > by > >> `StatusConfiguration`. > >> 4. Programmatically (i.e., `StatusLogger.getLogger().setLevel(...)`) > >> > >> `StatusConfiguration`-based configuration has certain caveats: > >> > >> - There is a time between the first `StatusLogger` access and a > >> configuration file (e.g., `log4j2.xml`) read. Hence, there is a time > window > >> that only the defaults will be effective. > >> - `StatusConfiguration` is created per `LoggerContext` and each LC > >> mutates the (globally shared!) `StatusLogger`. Hence, the last loaded > >> configuration always becomes the effective one. > >> > >> Given the purpose of `StatusLogger` (i.e., the logger of the logging > >> system) and above shortcomings related to `StatusConfiguration`, I want > to > >> remove the `StatusConfiguration`-based configuration in `main`. > Thoughts? > >> Objections? > > > >
