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? >