Overriding and Debugging Auto-configuration
A teammate adds the H2 database to library-service for quick experiments and forgets about it. Weeks later, the app starts on a server without its PostgreSQL settings and, instead of failing loudly, quietly runs on an empty in-memory database. Auto-configuration did exactly what it was told. When Boot's choices surprise you, you need two skills: seeing what it decided, and changing it.
The rule
Ask the report why; then override with a property, a bean, or an exclude.
Seeing what Boot decided. Start the app with --debug (or set debug=true) and Boot prints a condition evaluation report:
============================
CONDITIONS EVALUATION REPORT
============================
Positive matches:
DataSourceAutoConfiguration matched:
- @ConditionalOnClass found required classes 'javax.sql.DataSource' ...
Negative matches:
MongoDataAutoConfiguration:
Did not match:
- @ConditionalOnClass did not find required class 'com.mongodb.client.MongoClient'Positive matches were applied; negative matches were skipped, each with the reason. With Actuator, the same report is available at /actuator/conditions, and /actuator/beans lists every bean in the context.
Changing what Boot decided, from gentlest to strongest:
- A property. Most auto-configured beans read properties:
server.port,spring.datasource.url,spring.jpa.open-in-view=false. Try this first. - Your own bean. Define a bean of the same type and
@ConditionalOnMissingBeanmakes Boot's version back off. - An exclude. Switch off a whole auto-configuration class:
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class LibraryApplication { ... }or, without touching code, spring.autoconfigure.exclude= followed by the class's full name.
The shortcut
When Boot does something unexpected, report first, fix second, and use the gentlest fix that works. A property changes one detail, a bean replaces one object, an exclude removes a whole feature, so reach for them in that order.
Run the report
Start with
--debug. Under positive matches, the embedded database configuration matched: nospring.datasource.urlwas given and H2 was on the classpath.
The trap is jumping straight to exclude for every surprise. Excluding the data source auto-configuration to escape H2 would also switch off the PostgreSQL setup you need.
Drills
Answer fast — trust the rule.
How do you see which auto-configurations were applied and why?
You only want the app on port 9090 instead of 8080. What is the gentlest fix?
How do you switch off one auto-configuration class completely?
In the condition report, what does a negative match mean?
Remember
- Ask the report why; then override with a property, a bean, or an exclude.
- Report first, fix second, gentlest fix first: property, then bean, then exclude.
- Trap: excluding a whole feature to fix one detail.