Boot & Auto-Configuration
Why Spring Boot exists and how auto-configuration actually works - conditional beans that configure your app from the classpath.
On this page
In the Foundations module you learned the Spring container - beans, dependency injection, configuration. Powerful, but historically you had to configure a lot by hand: a web server, a JSON mapper, a data source, and dozens of other beans before your app did anything. Spring Boot exists to make all of that disappear.
Boot's promise: add a dependency, and the things it needs are configured automatically with sensible defaults. You override only what you actually care about.
The bare Spring Framework is like renting an empty apartment: enormous potential, but you must buy and arrange every piece of furniture before you can live there. Spring Boot is the same apartment delivered fully furnished - bed made, kitchen stocked, wifi on. You can move in immediately, and still swap out any piece you don't like. The furniture is the defaults; swapping is your configuration.
@SpringBootApplication
Every Boot app starts from one annotated class:
@SpringBootApplication
public class BookVaultApplication {
public static void main(String[] args) {
SpringApplication.run(BookVaultApplication.class, args);
}
}@SpringBootApplication is a convenience that bundles three annotations you already
half-know:
| Annotation | Does |
|---|---|
@Configuration | Marks this class as a source of bean definitions |
@ComponentScan | Scans this package (and below) for your @Service/@Repository/… beans |
@EnableAutoConfiguration | Turns on Boot's auto-configuration - the magic below |
How auto-configuration actually works
Auto-configuration is not magic - it's conditional beans. Boot ships hundreds of
auto-configuration classes, each guarded by @Conditional checks that ask questions
about your app and back off when they shouldn't apply:
// (simplified from Spring Boot's own source)
@AutoConfiguration
@ConditionalOnClass(DataSource.class) // only if JDBC is on the classpath
@ConditionalOnMissingBean(DataSource.class) // and you haven't defined one
public class DataSourceAutoConfiguration {
@Bean
DataSource dataSource(DataSourceProperties props) {
return props.initializeDataSourceBuilder().build();
}
}Read those conditions aloud: "If there's a DataSource class on the classpath, and the developer hasn't already defined their own DataSource bean, then create one for them." That's the whole mechanism, repeated across the framework:
@ConditionalOnClass- a type is on the classpath (i.e. you added a dependency).@ConditionalOnMissingBean- you haven't defined your own, so Boot provides a default.@ConditionalOnProperty- a config property has a certain value.
Your beans always win
Because auto-configuration backs off when a bean already exists
(@ConditionalOnMissingBean), you're never fighting Boot. Define your own bean and
Boot quietly steps aside. Convenient by default, fully overridable when you need it.
Seeing what got configured
Auto-configuration is transparent. Run with --debug and Boot prints a condition
evaluation report showing every auto-configuration and whether it matched and why:
Positive matches:
-----------------
DispatcherServletAutoConfiguration matched:
- @ConditionalOnClass found required class 'DispatcherServlet'
Negative matches:
-----------------
DataSourceAutoConfiguration:
- @ConditionalOnClass did not find required class 'javax.sql.DataSource'Nothing is hidden - you can always find out exactly why a bean does or doesn't exist.
Your app depends on spring-boot-starter-web, so Boot auto-configures a JSON
ObjectMapper bean for you. You then add your own @Bean ObjectMapper with custom
settings. Which ObjectMapper does the app use, and which @Conditional annotation
on Boot's auto-configuration makes that happen?
What mechanism does Spring Boot auto-configuration actually use?
Key takeaways
- Spring Boot layers auto-configuration and sensible defaults on top of the Spring Framework so apps start with almost no manual setup.
- @SpringBootApplication combines @Configuration, @ComponentScan, and @EnableAutoConfiguration.
- Auto-configuration is conditional beans: @ConditionalOnClass, @ConditionalOnMissingBean, and @ConditionalOnProperty decide what gets configured.
- Your own beans always take precedence, because auto-config backs off with @ConditionalOnMissingBean.
- Run with --debug to see the condition evaluation report - nothing is hidden.