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?
