skip to content

How do you make Spring Boot print the auto-configuration condition evaluation report, and what is it for?

level: juniorimportance: should knowfreq 55%

answer

  1. --debug / debug=true (not a log level)
  2. CONDITIONS EVALUATION REPORT
  3. Positive / Negative / Exclusions / Unconditional
  4. ConditionEvaluationReportLoggingListener
  5. auto-printed on startup failure

basics

~20 s

Start the app with the --debug flag (or set debug=true in application.properties). Spring Boot then logs a report showing which auto-configurations were applied and which were skipped, helping you understand why a bean did or didn't get created.

solid answer

~30 s

Run the app with the command-line flag --debug, or set debug=true in application.properties/application.yml (or the DEBUG env var). This does NOT switch every logger to DEBUG level; it specifically enables Spring Boot's ConditionEvaluationReportLoggingListener, which prints the CONDITIONS EVALUATION REPORT at INFO after the context refreshes. The report groups results into Positive matches (auto-configs applied), Negative matches (skipped, with the reason), Exclusions, and Unconditional classes. It's the first tool to reach for when a bean you expected is missing, or one you didn't expect appeared. You can also trigger it on a failed startup: a startup failure prints an abbreviated report automatically.

code

java · 21 lines
java
// application.properties
// debug=true

// or on the command line:
//   java -jar app.jar --debug

// Sample report excerpt:
// ============================
// CONDITIONS EVALUATION REPORT
// ============================
//
// Positive matches:
// -----------------
//   DataSourceAutoConfiguration matched:
//     - @ConditionalOnClass found required class 'javax.sql.DataSource' (OnClassCondition)
//
// Negative matches:
// -----------------
//   MongoAutoConfiguration:
//     Did not match:
//       - @ConditionalOnClass did not find required class 'com.mongodb.client.MongoClient' (OnClassCondition)

go deeper

for a junior

Know the three ways to enable it (--debug flag, debug=true, DEBUG env) and that it shows applied vs skipped auto-configs.

for a middle

Distinguish it from log levels; know the four report sections and that failures print it automatically.

for a senior

Explain the underlying listener and when the report is emitted (INFO after refresh vs failure analyzer).

for a principal

Frame it as the diagnostic entry point and know the programmatic/Actuator alternatives for automation.

## What the report is Spring Boot auto-configuration works by evaluating **conditions** (`@Conditional...` annotations) on many candidate configuration classes. Each candidate is either applied or skipped based on classpath contents, existing beans, properties, etc. The **condition evaluation report** is a human-readable dump of every one of those decisions. ## How to enable it Three equivalent ways: - **Command line:** `java -jar app.jar --debug` - **Property:** `debug=true` in `application.properties`, or `debug: true` in `application.yml` - **Environment variable:** `DEBUG=true` Important nuance: the `debug` property is a **special Spring Boot property**, not a logging level. It does NOT set the root logger to DEBUG. It enables a listener (`ConditionEvaluationReportLoggingListener`) that logs the report. (There's a sibling `trace=true` that additionally shows core Spring internals.) ## What it prints The report is titled `CONDITIONS EVALUATION REPORT` and has these sections: - **Positive matches** — auto-configuration classes (and their `@Bean` methods) whose conditions all matched, so they were applied. Each line lists the condition that matched and why (e.g. `@ConditionalOnClass found required class 'javax.sql.DataSource'`). - **Negative matches** — candidates that were skipped, with the failing condition and reason (e.g. `@ConditionalOnMissingBean ... found beans of type ...`). - **Exclusions** — classes explicitly excluded via `spring.autoconfigure.exclude` or `@SpringBootApplication(exclude=...)`. - **Unconditional classes** — configurations that carry no conditions and are always applied (e.g. `PropertyPlaceholderAutoConfiguration`). ## When it appears - On **successful** startup only when `debug`/`trace` is on. It logs at INFO after context refresh. - On a **startup failure**, Spring Boot prints an abbreviated version automatically (via `ConditionEvaluationReportFailureAnalyzer`) even without `--debug`, so you can see what conditions were involved in the broken area. ## Why it matters Auto-config is invisible magic until it misbehaves. The report turns 'why is there no DataSource bean?' into a concrete line telling you the exact condition that failed. It's the primary debugging entry point for 'expected bean missing' or 'unexpected bean present'. ## Gotcha Beginners often assume `--debug` cranks up all logging. It doesn't. To get verbose logs for a package use `logging.level.<package>=DEBUG`. `debug=true` is specifically about the condition report.

  • Does --debug turn on DEBUG logging for all your loggers?
    No. It only enables the condition evaluation report. To raise log verbosity per package you use logging.level.<package>=DEBUG. The debug/trace properties are dedicated Spring Boot flags, not root log-level switches.
  • Can you see the report even if the app fails to start?
    Yes. On a startup failure Spring Boot automatically prints an abbreviated condition evaluation report through its failure analyzer, no --debug needed.

saying these in an interview costs you the question

  • Claiming --debug sets the root logger to DEBUG level
  • Thinking the report is only available via Actuator and can't be printed to logs
  • Believing you must attach a debugger to see condition evaluation

context

resolving links…