skip to content

What is @EnableAutoConfiguration and how does it end up on your application?

level: juniorimportance: must knowfreq 78%

answer

  1. classpath-driven defaults
  2. @SpringBootApplication = config + scan + autoconfig
  3. @Import(AutoConfigurationImportSelector)
  4. back off via @ConditionalOnMissingBean
  5. put main class at package root

basics

~10 s

@EnableAutoConfiguration tells Spring Boot to automatically configure beans based on what's on the classpath. You rarely write it directly because @SpringBootApplication already includes it.

solid answer

~30 s

@EnableAutoConfiguration is the annotation that switches on Spring Boot's auto-configuration: it inspects the classpath, existing beans, and properties, then registers sensible default beans (a DataSource if a JDBC driver is present, a DispatcherServlet if spring-webmvc is present, and so on). You almost never add it yourself because the meta-annotation @SpringBootApplication bundles three things: @SpringBootConfiguration, @ComponentScan, and @EnableAutoConfiguration. Auto-configuration is 'best-effort and backs off': each candidate is guarded by @Conditional checks, so if you define your own bean of that type, Boot steps aside. This is why a Spring Boot app boots with almost no manual @Bean wiring.

code

java · 17 lines
java
// @SpringBootApplication already bundles @EnableAutoConfiguration
@SpringBootApplication
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }
}

// Equivalent, expanded form:
@SpringBootConfiguration
@ComponentScan
@EnableAutoConfiguration
public class MyAppExpanded {
    public static void main(String[] args) {
        SpringApplication.run(MyAppExpanded.class, args);
    }
}

go deeper

for a junior

Know that @SpringBootApplication includes @EnableAutoConfiguration and that Boot configures beans based on the classpath.

for a middle

Explain the composed annotation and the back-off behavior via conditions.

for a senior

Tie it to @Import(AutoConfigurationImportSelector) and ordering after user config.

for a principal

Discuss implications for library/starter design and how back-off makes Boot both opinionated and overridable.

## What it is `@EnableAutoConfiguration` is a Spring Boot annotation (package `org.springframework.boot.autoconfigure`) that turns on **auto-configuration** — Boot's mechanism for guessing and registering the beans you probably need, based on your **classpath**, your **already-defined beans**, and your **configuration properties**. ## Where it comes from You seldom write `@EnableAutoConfiguration` by hand. The standard entry annotation `@SpringBootApplication` is a **composed (meta-)annotation** equal to three annotations: - `@SpringBootConfiguration` — a specialization of `@Configuration` marking this class as the primary config source. - `@ComponentScan` — scans the annotated class's package and sub-packages for `@Component`/`@Service`/`@Repository`/`@Controller` and `@Configuration` classes. - `@EnableAutoConfiguration` — the subject of this question. So putting `@SpringBootApplication` on your main class implicitly enables auto-configuration. ## How it works, conceptually `@EnableAutoConfiguration` is itself annotated with `@Import(AutoConfigurationImportSelector.class)`. At startup that selector reads a list of **auto-configuration candidate classes** shipped by Boot and every starter on the classpath, then registers each candidate — but each candidate class is guarded by `@Conditional` annotations (for example `@ConditionalOnClass`, `@ConditionalOnMissingBean`, `@ConditionalOnProperty`). A candidate only contributes its beans when its conditions match. The crucial property is **back-off**: `@ConditionalOnMissingBean` means 'only create this bean if the user hasn't already defined one.' So auto-configuration provides defaults but always yields to your explicit configuration. That is what lets a Boot app start with essentially zero manual wiring, yet remain fully overridable. ## A concrete example If `spring-boot-starter-web` is on the classpath, `WebMvcAutoConfiguration` and `DispatcherServletAutoConfiguration` fire and you get an embedded Tomcat, a `DispatcherServlet`, Jackson message converters, etc. Remove the web starter and those simply don't activate — no error, they just back off because their `@ConditionalOnClass` guards no longer match. ## Gotchas - **Package placement matters** because of the bundled `@ComponentScan`, not auto-configuration itself: put your main class at the **root** of your package tree so scanning reaches everything. - Auto-configuration classes are applied **after** your own user configuration, precisely so `@ConditionalOnMissingBean` can see your beans and back off. - Enabling it twice (e.g., `@SpringBootApplication` plus a redundant `@EnableAutoConfiguration`) is unnecessary and Boot will complain about more than one auto-configuration attempt. ## When to use it directly Almost never in application code. You'd use the bare `@EnableAutoConfiguration` (without component scanning) mainly in slim test slices or minimal apps where you want auto-config but not a full component scan.

  • What three annotations does @SpringBootApplication combine?
    @SpringBootConfiguration, @ComponentScan, and @EnableAutoConfiguration.
  • Why can you override an auto-configured bean just by declaring your own?
    Because auto-configuration classes are guarded by @ConditionalOnMissingBean and applied after user config, so they back off when you already provide that bean.

saying these in an interview costs you the question

  • Claiming @EnableAutoConfiguration scans your packages for components (that's @ComponentScan, a separate part of @SpringBootApplication).
  • Saying auto-configuration always wins over your beans (it backs off via @ConditionalOnMissingBean).
  • Thinking you must add @EnableAutoConfiguration yourself alongside @SpringBootApplication.

context

resolving links…