Externalized Configuration & Profiles
Everything about getting configuration into a Boot app: property source precedence, type-safe binding, validation, profiles, config import and secrets, environment post-processing, and IDE metadata. Config questions are practical and they separate people who have deployed from people who have only run locally.
part ofSpring Frameworkoverview, primer and where to startread it →on this pageshowhide
explore
- Property sources & precedence5 questions
- @ConfigurationProperties & relaxed binding5 questions
- Validating bound config5 questions
- Spring profiles5 questions
- Config import, trees & secrets5 questions
- EnvironmentPostProcessor SPI5 questions
- Configuration property metadata5 questions
questions
page 2 of 2You own the config strategy for a service deployed to dev/staging/prod containers. How do you use Spring Boot's property sources and precedence to layer defaults, per-environment overrides, and secrets safely?
basics
~20 sShip one immutable jar with safe defaults in application.yml, add profile-specific files for structural per-environment differences, and override the rest at runtime with environment variables (which outrank the files). Inject secrets from a secrets manager, never bake them into packaged files.
When should you use an EnvironmentPostProcessor versus the ConfigData API or @ConfigurationProperties, and how do multiple EPPs order against Boot's own ConfigDataEnvironmentPostProcessor?
basics
~20 sUse an EPP for broad, imperative shaping of the whole Environment early (compute/decrypt/inject property sources). Use the ConfigData API to add a new config location type (like a custom spring.config.import). Use @ConfigurationProperties only to read config into beans. Order EPPs with Ordered/@Order; Boot's ConfigDataEnvironmentPostProcessor runs at very high precedence.
A team's @ConfigurationProperties keys aren't showing up in IDE auto-completion. Walk through the likely causes, including Kotlin and incremental-build pitfalls.
basics
~10 sCheck that the configuration-processor is on the annotation-processor path (kapt for Kotlin), that properties have getters/setters or constructor binding, that nested non-inner types use @NestedConfigurationProperty, and that the project was rebuilt so spring-configuration-metadata.json regenerated.
When should you avoid @Profile-based bean wiring, and what problems do profiles cause at scale?
basics
~10 sUse profiles for coarse environment differences, not for fine-grained feature toggles. Overusing @Profile scatters conditional wiring, makes tests fragile, and hides which beans exist. Prefer @ConditionalOnProperty or config values for feature flags.
How do you add custom, cross-field validation to bound config, and how do conversion and validation order interact when designing a config surface?
basics
~20 sRegister a Spring Validator bean named exactly configurationPropertiesValidator (often static) to enforce cross-field rules, or write a class-level custom JSR-380 constraint. The binder converts strings to target types first, then validation runs on the converted object.
showing 31–35 of 35