SpringApplication startup failure report silently discarded when commons-logging resolves to Jdk14Logger (regression from 3.5.x)

When the application context fails to refresh (e.g. a BeanCreationException), Spring Boot 4.0.x silently discards the entire failure report — no stacktrace, no FailureAnalyzer output, no Application run failed line — if org.apache.commons.logging.LogFactory resolves to Jdk14Logger rather than the SLF4J adapter. The process exits with code 1 after a single WARN from AnnotationConfigApplicationContext. The same setup prints the full stacktrace correctly in 3.5.x.

Affected versions

• Reproduces: Spring Boot 4.0.6 (likely all 4.0.x)
• Works: Spring Boot 3.5.14

Reproducer

https://github.com/cziberpv/spring-boot-silent-failure-mre

git clone https://github.com/cziberpv/spring-boot-silent-failure-mre.git
cd spring-boot-silent-failure-mre
mvn -DskipTests package
java -cp "target/classes:target/lib/*" com.example.MreApplication

(Windows: replace : with ; in the classpath.)

The reproducer is a spring-boot-starter app with one @Service whose constructor throws. The single deviation from defaults is an explicit commons-logging:1.2 dependency in pom.xml — a realistic situation in enterprise migrations, where legacy libraries (Saperion, httpclient 4.x, JCIFS, custom SOAP/ORM stacks, etc.) pull in commons-logging:1.2 transitively and Maven's nearest-wins resolution lets it replace the 1.3.x copy that Spring Boot 4 expects.

Commenting out that single dependency in pom.xml and rebuilding makes the bug disappear — see expected.txt vs actual.txt in the repo.

Expected behavior

ERROR --- o.s.boot.SpringApplication : Application run failed

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'failingService' ...
    at ...
Caused by: java.lang.RuntimeException: Simulated startup failure ...
    at com.example.FailingService.<init>(FailingService.java:8)

Actual behavior

2026-05-12T...  INFO ... Starting MreApplication ...
2026-05-12T...  INFO ... No active profile set ...
2026-05-12T...  WARN ... Exception encountered during context initialization
                       - cancelling refresh attempt: ... Constructor threw exception
[process exits with code 1, nothing else printed]

Root cause

Spring Boot 4.0.x replaced spring-jcl (which hard-coded SLF4J and ignored JCL discovery) with apache commons-logging:1.3.x. Apache commons-logging performs runtime discovery whose result depends on which commons-logging jar is loaded by the classloader:

• commons-logging:1.2 ships only Avalon / JDK13 / JDK14 / Log4j / LogKit / Simple log adapters. No SLF4J adapter exists in the artifact. With no JCL discovery overrides on the classpath, the default LogFactoryImpl resolves to Jdk14Logger.
• commons-logging:1.3.x added Slf4jLogFactory and auto-selects it when SLF4J is on the classpath — this is what makes Spring Boot 4 work in the default configuration.

When commons-logging:1.2 ends up earlier on the classpath (or replaces 1.3.x via Maven nearest-wins), LogFactory is loaded from 1.2 and the SLF4J integration shipped in 1.3.x is unreachable. From that point on, every LogFactory.getLog(...) call in Spring Framework / Spring Boot returns a Jdk14Logger.

The silent failure on top of that is in Spring Boot itself:

1. AbstractApplicationContext.refresh() fails and logs a WARN without stacktrace (string concatenation, not logger.warn(msg, ex)).
2. SpringApplication.handleRunFailure() calls listeners.failed(...) first → LoggingApplicationListener.onApplicationFailedEvent() → cleanupLoggingSystem() → LogbackLoggingSystem.cleanUp() → removeJdkLoggingBridgeHandler(). The SLF4JBridgeHandler is removed from the JUL root logger; the original JUL ConsoleHandler was already removed when the bridge was installed. The JUL root logger now has zero handlers.
3. handleRunFailure() then calls reportFailure() in its finally block. LoggingFailureAnalysisReporter.report() (or the fallback logger.error("Application run failed", failure)) goes through Jdk14Logger → java.util.logging.Logger → no handlers → silently discarded.
4. SpringBootExceptionHandler.uncaughtException() sees the exception is registered as "logged", does not delegate to the parent handler, and System.exit(1) is called.

In 3.5.x, spring-jcl does not honor JCL discovery — LogFactory.getLog(...) always returns an SLF4J-backed logger, the failure log is routed through Logback's ConsoleAppender, and the stacktrace is printed normally.

Verified via JDWP

On the original deployment the reporter attached a debugger and confirmed:

1. Breakpoint at SpringApplication.java:854 (if (logger.isErrorEnabled())) — hit
2. logger.isErrorEnabled() — returns true
3. logger.error("Application run failed", failure) — executes
4. logger runtime type — Jdk14Logger (not SLF4J)
5. java.util.logging.Logger.getLogger("").getHandlers() — empty array
6. The logger.error(...) call writes to JUL with no handlers → output is discarded

Why fat-jar / IDE do NOT reproduce

• java -jar app.jar (Spring Boot's JarLauncher with the nested BOOT-INF/lib/... layout) iterates jars in the order recorded in BOOT-INF/classpath.idx, where commons-logging:1.3.x precedes any older copy. The exploded lib/* layout used in production deployments expands alphabetically via the JVM glob, putting 1.2 first.
• IntelliJ IDEA constructs the launch classpath from the resolved Maven model, which deduplicates artifacts before launching, so the duplicate commons-logging:1.2 never appears at runtime.

This means the bug is invisible during local java -jar runs and IDE runs, and only manifests in production-style classpath layouts (Maven Assembly, custom distribution, install4j, etc.) — making it particularly hard to diagnose.

Suggested fix

The fix is independent of how JCL ends up resolving to Jdk14Logger — the underlying problem is that cleanupLoggingSystem() removes JUL handlers before reportFailure() writes the final error, and any JUL-routed log call after cleanup is silently lost.

Three options, in increasing order of invasiveness (full discussion in the README of the reproducer):

1. Reorder in SpringApplication.handleRunFailure(): call reportFailure() before listeners.failed(context, exception), so the failure report is logged while the logging system is still alive. Most targeted.
2. Restore a JUL ConsoleHandler in AbstractLoggingSystem.cleanUp() after removing the SLF4J bridge handler, so any JUL-routed log call can still reach stderr. Fixes the broader class of "anything logged after cleanup is lost".
3. System.err safety net in SpringApplication.reportFailure() — write to System.err after the normal logger path, conditional on cleanupLoggingSystem() having already run. Most defensive.

Environment

• Java 21.0.7 (Amazon Corretto)
• Spring Boot 4.0.6 (Spring Framework 7.0.7, Spring Boot 4.0.x default Logback)
• Linux and Windows production deployments; reproducer verified on Windows 11 with Maven 3.9.14

Start with SpringApplication.handleRunFailure() and reportFailure(), then trace LoggingApplicationListener cleanup through AbstractLoggingSystem and LogbackLoggingSystem. Run the linked reproducer using its exploded lib/* classpath and compare expected.txt with actual.txt. Done means the startup failure report remains visible when commons-logging:1.2 resolves to Jdk14Logger, without regressing normal startup failure logging.