How does Logback find and load its configuration at startup, what is the precedence between logback-test.xml, logback.xml and the logback.configurationFile system property, and how do you debug a configuration that appears to be ignored?

## Lazy, once, per context Logback does not configure at JVM start. The first call that touches the `LoggerContext` triggers `ContextInitializer`, which runs the lookup and applies whatever it finds. Everything before that point is uninitialised, which is why a property set programmatically in `main()` after some static logger has already been touched has no effect. ## The resolution order 1. The system property `logback.configurationFile` — a filesystem path, a URL, or a classpath resource name. This is the deployment-time override, and the only one that lets a container point at a file outside the artifact. 2. `logback-test.xml` on the classpath. 3. `logback.xml` on the classpath. 4. A `Configurator` implementation discovered through the JDK service loader (`META-INF/services`). 5. Otherwise `BasicConfigurator`: one console appender, root at DEBUG. This default is why an unconfigured app is unexpectedly chatty. Only the **first** matching classpath resource is used, and classpath order across jars is not something you control reliably. Shipping `logback.xml` inside a library is therefore a known anti-pattern: it may win over the application's own file. `logback-test.xml` exists precisely so tests can win without editing the production file — its risk is leaking into a runtime classpath through a badly scoped test dependency. ## Parsing The XML is interpreted by **Joran**, a rule-based configurator that maps element paths to actions and instantiates classes reflectively, setting properties from attributes and child elements via JavaBean setters. Two consequences follow. First, an unknown element or a misspelled property is usually a *warning*, not a hard failure — the surrounding configuration still applies, so a silently wrong appender is entirely possible. Second, any class named in the file must be on the classpath at configuration time, so a missing encoder dependency shows up as a status error rather than an exception in your code. Substitution uses `${name}` resolved against, in order, local `<property>` and `<variable>` definitions, system properties, and environment variables; `${VAR:-default}` supplies a fallback. `<springProfile>`-style conditionals are not native — plain Logback offers `<if>/<then>/<else>` conditional blocks (requiring the Janino library) and `<include>` for composing files. ## Status: how you actually debug it Logback keeps an internal `StatusManager` list because it cannot log its own bootstrap through itself. Nothing prints from it unless an error occurred or you asked. Three ways to ask: - `<configuration debug="true">` — prints status from the point the file is parsed. - `-Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener` — prints from *before* the file is located, which is the version you want when the question is "which file did it even load?". - Add `<statusListener class="...OnConsoleStatusListener"/>` as the first child element. The first status line names the resolved URL. If it points into a dependency jar, you have your answer without further guessing. ## Reloading `scan="true"` attaches a `ReconfigureOnChangeTask` that checks the file's modification time every `scanPeriod` (default one minute) and reconfigures the whole context on change. Reconfiguration replaces appenders, so file handles are reopened and any in-flight async queue is drained or dropped depending on the appender's stop semantics — it is not free, and a scan period of a few seconds on a large config is a real cost. If the new file fails to parse, Logback falls back to a safe configuration rather than leaving you with nothing, and says so in status. For runtime level changes without file editing, the `LoggerContext` API (`getLogger(name).setLevel(...)`) or a JMX configurator is the more surgical tool; scanning is the fire-and-forget option.