skip to content

What is a custom auto-configuration in Spring Boot, and how do you register it so Spring Boot picks it up automatically?

level: juniorimportance: must knowfreq 55%

answer

  1. @AutoConfiguration class, not component-scanned
  2. AutoConfiguration.imports file, one FQN per line
  3. META-INF/spring/ path exact
  4. read by @EnableAutoConfiguration selector
  5. spring.factories = old way, removed in 3.0

basics

~10 s

A configuration class annotated with @AutoConfiguration that defines @Bean methods. You register it by listing its full class name in the file META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports so Spring Boot loads it on startup.

solid answer

~40 s

Auto-configuration is Spring Boot's way of contributing beans automatically based on what's on the classpath, without the user declaring them. To write your own, create a class annotated with @AutoConfiguration (Spring Boot 2.7+) containing @Bean methods, usually guarded by @Conditional annotations so they only activate when appropriate. Registration is not via component scanning: you list the fully qualified class name, one per line, in src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. At startup, @EnableAutoConfiguration (pulled in by @SpringBootApplication) reads every such file from every jar on the classpath and evaluates the listed classes. This decoupling is what lets a library ship beans that 'just work' when its jar is added, while still letting the application override them.

code

java · 20 lines
java
// src/main/java/com/acme/greeting/GreetingAutoConfiguration.java
package com.acme.greeting;

import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.context.annotation.Bean;

@AutoConfiguration
public class GreetingAutoConfiguration {

    @Bean
    public GreetingService greetingService() {
        return new GreetingService("Hello");
    }
}

// src/main/resources/META-INF/spring/
//   org.springframework.boot.autoconfigure.AutoConfiguration.imports
//
// Contents (one fully qualified class name per line):
// com.acme.greeting.GreetingAutoConfiguration

go deeper

for a junior

Must know: @AutoConfiguration + list the class in the AutoConfiguration.imports file. That's the core.

for a middle

Should also name the exact file path and know it replaced spring.factories in 2.7.

for a senior

Explains why scanning isn't used and how @EnableAutoConfiguration/the import selector reads and orders the entries.

for a principal

Frames this as library-design decoupling and knows the migration history (spring.factories deprecation → removal in 3.0).

**What auto-configuration is.** In Spring Boot, *auto-configuration* means the framework automatically creates and wires beans for you based on the classpath, existing beans, and properties — so adding a jar can make features 'just work' without you writing @Configuration yourself. Spring Boot ships hundreds of these (for DataSource, Jackson, web MVC, etc.). *Custom* auto-configuration is you doing the same thing for your own library or shared module. **The annotation.** Since Spring Boot 2.7 you annotate the class with `@AutoConfiguration` (package `org.springframework.boot.autoconfigure`). It is meta-annotated with `@Configuration(proxyBeanMethods = false)`, so it *is* a configuration class, plus it carries ordering hints (`before`/`after`). Inside it you declare `@Bean` methods just like any `@Configuration` class. **Why it is NOT component-scanned.** A regular `@Configuration` in your app is found by `@ComponentScan`. Auto-configuration classes deliberately live *outside* your app's scan path (they're in library jars) and must load in a controlled, ordered, conditional way. So they are discovered through a registration file, not scanning. **The registration file (Spring Boot 2.7+ / 3.x).** Create: `src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports` Each line is one fully qualified class name, e.g. `com.acme.greeting.GreetingAutoConfiguration`. Blank lines and `#` comments are allowed. Every jar on the classpath can contribute its own copy of this file; Spring Boot merges them all. **How it's read at runtime.** `@SpringBootApplication` includes `@EnableAutoConfiguration`, which imports `AutoConfigurationImportSelector`. That selector loads all `AutoConfiguration.imports` entries, applies filtering/conditions, orders them, and registers the surviving classes as configuration — *after* your own user configuration, which matters for conditional back-off. **The legacy mechanism (pre-2.7).** Older projects registered auto-configs in `META-INF/spring.factories` under the key `org.springframework.boot.autoconfigure.EnableAutoConfiguration=...`. That key is deprecated as of 2.7 and **removed in Spring Boot 3.0** — use the `.imports` file. Knowing both is useful because you'll see `spring.factories` in older codebases. **Gotchas.** - The file path and filename must be *exact* — a typo means silent non-loading (no error, beans just never appear). - The listed class must be public with a no-arg constructor. - Don't also put the class under `@ComponentScan`, or it may be registered twice / lose ordering guarantees. - Auto-config beans should almost always be guarded by conditions (e.g. `@ConditionalOnMissingBean`) so the app can override them. **When to use.** Write custom auto-configuration when you ship a reusable library or internal shared starter and want consumers to get sensible default beans just by adding the dependency.

  • What was the older registration mechanism and is it still supported?
    Before Spring Boot 2.7 you registered auto-configs in META-INF/spring.factories under the EnableAutoConfiguration key. That approach is deprecated since 2.7 and removed in Spring Boot 3.0; the AutoConfiguration.imports file replaces it.
  • Why aren't auto-configuration classes just picked up by @ComponentScan?
    They live in library jars outside the app's scan base package and must be loaded conditionally and in a controlled order, after user config. The imports-file mechanism gives Spring Boot that control; scanning would not.

saying these in an interview costs you the question

  • Thinking auto-config classes are found via @ComponentScan
  • Putting the imports file at the wrong path (e.g. under META-INF/services)
  • Believing spring.factories still works for auto-config in Spring Boot 3
  • Registering the class with both @ComponentScan and the imports file

context

resolving links…