skip to content

Walk me through the sections of the condition evaluation report and what each tells you.

level: middleimportance: should knowfreq 45%

answer

  1. 4 sections: Positive / Negative / Exclusions / Unconditional
  2. Negative = 'Did not match' + reason to fix
  3. OnClass missing → add dependency
  4. OnMissingBean found → you already defined it
  5. Exclusions = spring.autoconfigure.exclude

basics

~20 s

The report has four parts: Positive matches (auto-configs that were applied and why), Negative matches (ones skipped and the condition that failed), Exclusions (explicitly excluded configs), and Unconditional classes (configs with no conditions that always load).

solid answer

~40 s

Positive matches show every auto-config class and @Bean method whose conditions all passed, each annotated with the matching condition (e.g. @ConditionalOnClass, @ConditionalOnProperty) and a short reason. Negative matches show candidates that were skipped, listing the condition that failed AND the reason — this is where you look when an expected bean is missing (typical: @ConditionalOnClass didn't find a class, or @ConditionalOnMissingBean found an existing bean). Exclusions lists classes removed via spring.autoconfigure.exclude or @SpringBootApplication(exclude=). Unconditional classes are configs with no @Conditional, always applied. Reading it is a top-down process: search the Negative section for the auto-config you expected, and the reason line tells you exactly which condition to fix (add a dependency, set a property, remove a conflicting bean).

code

java · 17 lines
java
// Reading a Negative match to diagnose a missing DataSource:
//
// Negative matches:
// -----------------
//   DataSourceAutoConfiguration:
//     Did not match:
//       - @ConditionalOnClass did not find required class
//         'javax.sql.DataSource' (OnClassCondition)
//
// Fix: the JDBC starter isn't on the classpath.
//   implementation("org.springframework.boot:spring-boot-starter-jdbc")

// Reading why auto-config backed off because YOU defined the bean:
//   JacksonAutoConfiguration#objectMapper:
//     Did not match:
//       - @ConditionalOnMissingBean (types: com.fasterxml.jackson.databind.ObjectMapper)
//         found beans 'myObjectMapper' (OnBeanCondition)

go deeper

for a junior

Name the four sections and that Negative tells you why something was skipped.

for a middle

Map common reason strings (OnClass/OnMissingBean/OnProperty) to concrete fixes.

for a senior

Explain class-level vs @Bean-level conditions and that one failing condition skips a candidate.

for a principal

Discuss reliability of reason text, ConditionOutcome source, and ordering-sensitivity of OnMissingBean.

## The mental model Auto-configuration = a big list of candidate `@Configuration` classes, each gated by conditions. The report is the audit log of how every gate resolved. Four sections: ### 1. Positive matches Auto-configs (and individual `@Bean` methods within them) whose conditions **all matched**, so they were applied. Example: ``` DataSourceAutoConfiguration#dataSource matched: - @ConditionalOnMissingBean (types: javax.sql.DataSource) did not find any beans (OnBeanCondition) - @ConditionalOnProperty (spring.datasource.url) matched (OnPropertyCondition) ``` Each bullet is a condition and why it passed. If a bean you wanted is here, it was created. ### 2. Negative matches Candidates that were **skipped**. Each shows `Did not match:` with the failing condition(s). This is the workhorse section for debugging. Common reasons: - `@ConditionalOnClass did not find required class '...'` → a dependency is missing from the classpath. - `@ConditionalOnMissingBean ... found beans of type '...'` → you (or another config) already defined that bean, so auto-config backed off. - `@ConditionalOnProperty (x.y.z) did not find property` or matched a wrong value. - `@ConditionalOnMissingClass found unwanted class` → something on classpath vetoed it. Note: a config only needs ONE condition to fail to be skipped; the report shows the ones that didn't match. ### 3. Exclusions Auto-configs explicitly excluded via `spring.autoconfigure.exclude=...` or `@SpringBootApplication(exclude = {X.class})` / `@EnableAutoConfiguration(exclude=...)`. They never even evaluate their conditions. ### 4. Unconditional classes Configurations carrying **no** `@Conditional` annotation — they always apply. Examples include `PropertyPlaceholderAutoConfiguration`. Useful to confirm baseline infrastructure is present. ## How to actually use it 1. Reproduce with `--debug`. 2. Ctrl-F the auto-config class name you care about (e.g. `RedisAutoConfiguration`). 3. If it's under **Positive** → it ran; the problem is elsewhere (property, profile). 4. If under **Negative** → read the reason line; it names the exact condition to satisfy. 5. If under **Exclusions** → someone excluded it deliberately. ## Gotchas - Nested `@Bean` methods have their own condition lines, so a class can be a Positive match overall while one of its beans is negative. - The reason text comes from the `Condition` implementations (`OnClassCondition`, `OnBeanCondition`, `OnPropertyCondition`) via `ConditionOutcome` — it's not free text you can rely on parsing, but it's stable enough to read. - Ordering of `@ConditionalOnMissingBean` evaluation depends on config ordering; a bean defined 'later' may not be seen. That surprises people (covered in the missing-bean question).

  • If an auto-config appears under Positive matches but the bean still isn't behaving, where do you look next?
    The config ran, so check its @Bean-level condition lines (a nested bean may be negative), the actual property values driving it, and active profiles — the wiring happened but configuration input may be wrong.
  • What's the difference between a Negative match and an Exclusion?
    A Negative match means the config's conditions were evaluated and failed. An Exclusion means it was removed before evaluation via spring.autoconfigure.exclude or exclude= on the annotation, so its conditions never ran.

saying these in an interview costs you the question

  • Confusing Exclusions with Negative matches
  • Assuming a Positive class means all its beans were created (nested @Bean conditions can differ)
  • Thinking a config needs all conditions to fail to be skipped — one failing condition is enough

context

resolving links…