Lesson 15 · Spring Boot · starts Section 6

Spring Boot — Auto-configuration & Properties

Starters, @SpringBootApplication, how auto-configuration actually decides what to create, and where properties come from.

What you'll be tested on What a starter is and how Boot manages dependency versions; the three annotations inside @SpringBootApplication; how auto-configuration works (conditions, spring.factories) and how to override or exclude it; and property loading & precedence.

Boot's promise: opinionated defaults

Spring Boot is opinionated — it applies sensible industry defaults so you configure only what differs. Its pillars: starters, auto-configuration, an embedded server, and Actuator (Lesson 16).

Starters & dependency management

A starter (e.g. spring-boot-starter-web) is a dependency descriptor — one entry that pulls in a curated, version-compatible set of libraries for a feature.
spring-boot-starter-parent (or the spring-boot-dependencies BOM) manages versions, so you can omit <version> on managed dependencies.

`@SpringBootApplication`

The one annotation on your main class is shorthand for three:

@SpringBootApplication
// = @SpringBootConfiguration + @EnableAutoConfiguration + @ComponentScan
public class App {
  public static void main(String[] args) {
    SpringApplication.run(App.class, args);   // boots the context + embedded server
  }
}

Boot packages the app as a runnable executable ("fat") JAR — your classes plus every dependency — launched with java -jar app.jar. To run code once at startup, implement CommandLineRunner or ApplicationRunner.

Boot's defaults worth knowing

Concern	Default
Embedded server	Tomcat (alternatives: Jetty, Undertow)
JSON	Jackson
Logging	Logback, default level INFO (Commons Logging is the internal facade)
Config file	`application.properties` / `application.yml`

How auto-configuration works

@EnableAutoConfiguration (inside @SpringBootApplication) triggers it. Boot reads a list of auto-configuration classes from META-INF/spring.factories, and each class is guarded by @Conditional annotations that decide whether it applies:

Condition	Applies the config only if…
`@ConditionalOnClass`	a class is on the classpath
`@ConditionalOnMissingBean`	you haven't already defined that bean
`@ConditionalOnProperty`	a property has a given value
`@ConditionalOnBean` / `OnWebApplication`	a bean exists / it's a web app

Your config always wins Auto-config uses @ConditionalOnMissingBean, so if you define a bean, Boot backs off and uses yours. To switch an auto-config off entirely: @SpringBootApplication(exclude = DataSourceAutoConfiguration.class) or the spring.autoconfigure.exclude property.

Properties & precedence

Define properties in application.properties/.yml; profile-specific in application-{profile}.properties.
Read them with @Value("${...}") or bind a group to a typed bean with @ConfigurationProperties(prefix = "app").
Precedence (high → low, abridged): command-line args → SPRING_APPLICATION_JSON → OS environment variables → application-{profile}.properties → application.properties → @PropertySource → defaults.

Highest precedence = command-line arguments A value passed as --server.port=9000 overrides the same key in every file. Later/more-specific sources win.

Primary source — read this

Spring Boot 2.5 — Auto-configuration & Externalized Configuration

Read "Auto-configuration", "Structuring Your Code", and "Externalized Configuration" (the property-source order list).

Check yourself

The auto-config mechanics (conditions, spring.factories, overriding) and property precedence are the money questions. Options shuffle on every load.

Second pass The same ground spans your book's Boot Intro and Boot AutoConfig sections. One lesson left — Actuator — then the course is complete.

I'm your teacher — ask me anything. Want to see a custom auto-configuration class with @ConditionalOnMissingBean, or a @ConfigurationProperties example? Ask. Say "continue" for the final lesson — Actuator.

← Lesson 14 · Spring Security Lesson 16 · Actuator → (coming next)