Introduction

If a Spring Boot application appears to ignore -Dlogback.configurationFile=..., the usual reason is that Spring Boot initializes logging through its own LoggingSystem very early in startup. In Boot applications, the most reliable override is usually logging.config or a logback-spring.xml file, not a plain Logback system property used the same way as in a non-Boot app.

The First Thing to Check: Command Syntax

The title of this question already hints at one common mistake: the JVM property must include an equals sign and must appear before -jar.

Correct:

java -Dlogback.configurationFile=/opt/app/logback.xml -jar app.jar

Wrong:

java -jar app.jar -Dlogback.configurationFile=/opt/app/logback.xml

Arguments after -jar are passed to the application, not treated as JVM system properties.

Also note that the title string -Dlogback.configurationFilelogback.xml is missing the equals sign entirely. That exact form would not work as a valid property assignment.

Why Spring Boot Behaves Differently

Plain Logback can read logback.xml or -Dlogback.configurationFile directly. Spring Boot adds another layer: it detects the logging framework and configures it before the application context is fully built.

Boot prefers configuration paths that it controls because it adds features such as:

• profile-aware logback configuration
• property resolution from the Spring environment
• Boot-specific defaults and extensions

That is why logback-spring.xml is often preferred over logback.xml in Boot projects.

Prefer logging.config in Spring Boot

The Boot-friendly override is usually:

java -Dlogging.config=/opt/app/logback-spring.xml -jar app.jar

You can also set it in configuration:

logging.config=/opt/app/logback-spring.xml

This property is recognized by Spring Boot's logging initialization path, which makes it more predictable than relying on Logback alone.

logback.xml Versus logback-spring.xml

If your file uses Spring-specific features, you should use logback-spring.xml and let Boot load it. For example, Spring profile sections and environment placeholders are supported only through Boot's enhanced loading path.

A small example:

1<configuration>
2  <springProperty scope="context" name="appName" source="spring.application.name"/>
3
4  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
5    <encoder>
6      <pattern>%d %-5level [%thread] %logger - %msg%n</pattern>
7    </encoder>
8  </appender>
9
10  <root level="INFO">
11    <appender-ref ref="STDOUT"/>
12  </root>
13</configuration>

That style belongs in logback-spring.xml, not in a plain Logback bootstrap flow.

Other Reasons the File Appears Ignored

The File Is Not Reachable

If the path is relative, the JVM working directory may not be what you expect. Use an absolute path while debugging.

Another Config Is Winning

If the classpath already contains logback-spring.xml or logback.xml, and your startup wiring favors it, the external file may appear to lose. Inspect the startup logs carefully because Logback usually prints which configuration resource it loaded.

The App Is Repackaged or Launched Differently

Running from an IDE, Maven plugin, container entrypoint, or shell wrapper can change where JVM arguments are inserted. Confirm the actual Java command line being executed.

A Reliable Debugging Sequence

Use this sequence when diagnosing the issue:

1. verify the JVM argument is before -jar
2. use an absolute file path
3. prefer -Dlogging.config=... for Spring Boot
4. remove conflicting in-classpath logback files during the test
5. check startup logs for the chosen config resource

That process usually isolates the problem quickly.

Common Pitfalls

A common mistake is assuming Boot treats -Dlogback.configurationFile exactly like a plain Java application. Boot's logging bootstrap is more opinionated.

Another pitfall is using logback.xml when the configuration depends on Spring features. In that case the file may load, but the Spring-specific parts will not behave as expected.

Developers also often place the JVM property after -jar, which makes it invisible to the JVM.

Summary

• Make sure the property syntax is valid and appears before -jar.
• Spring Boot usually works more predictably with logging.config.
• Prefer logback-spring.xml when using Spring-aware logging features.
• Check for conflicting classpath files and relative-path issues.
• In Boot, logging problems are often startup-order problems rather than Logback bugs.