Ankur Mhatre
86246dc860
configuration-properties/ @ConfigurationProperties vs @Value on Spring Boot 4.1.1. The relaxed-binding matrix is generated by binding each spelling rather than transcribed, and re-checked against real processes -- the in-process probe was wrong twice before it was right. Records the three findings that came out of it: @Value does get relaxed resolution inside Spring Boot (Boot attaches ConfigurationPropertySources), the configuration processor silently stops generating metadata on JDK 23+ when declared as a plain dependency, and @Valid is not what makes nested constraints run. profiles-and-config/ Precedence, profiles, spring.config.import and config trees. /precedence reports every source holding a property in rank order with file and line, which turns "my profile file had no effect" into a two-line answer. Also pins the counterintuitive one: an imported file outranks the file that imported it. spring-aop/ Designators, proxy types, and aspects that do not fire. One advice per supported designator so the reference table is generated from real matches; all fourteen unsupported designators fed to the parser. Two corrections to the reference documentation: unsupported designators throw UnsupportedPointcutPrimitiveException (extends RuntimeException, not IllegalArgumentException), and spring-boot-starter-aop was renamed to spring-boot-starter-aspectj in Boot 4. 19 contract tests across the three modules, 15 captured transcripts, all regenerated by scripts/run-all.sh. Verified on Spring Boot 4.1.1, Spring Framework 7.0.9, JDK 25.0.4.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gip4srpzMwjgoba6uEfbr5
1.9 KiB
← Relaxed binding · Index · Records and defaults →
3. Getting the bean registered
@ConfigurationProperties on a class does nothing on its own. The class has to become a bean,
and there are three ways to arrange that:
| How | Where it goes | When to use it |
|---|---|---|
@ConfigurationPropertiesScan |
on the application class | most applications; scans a package |
@EnableConfigurationProperties(Foo.class) |
on any @Configuration class |
libraries, or when you want the list explicit |
@Component |
on the properties class itself | works, but mixes a stereotype into a value type |
This project uses @ConfigurationPropertiesScan, on
ConfigBindingApplication.
The failure
If none of the three is present, the class compiles, the application starts, and the bean does
not exist. Injecting it fails with NoSuchBeanDefinitionException — which is at least loud.
The quiet version is worse: with constructor binding, a properties record that is never registered simply never appears, and if the only thing that used it was optional, nothing complains at all.
Constructor binding and @Autowired do not mix
A type bound through its constructor is built by the binder, not by the container. It cannot have collaborators injected into that constructor, because every parameter is treated as a property to bind. If a properties type needs a collaborator, it is not a properties type.
@ConfigurationProperties on an @Bean method
Legal, and useful when the type comes from a library you cannot annotate:
@Bean
@ConfigurationProperties(prefix = "demo.thirdparty")
ThirdPartyConfig thirdPartyConfig() {
return new ThirdPartyConfig();
}
This uses setter binding, not constructor binding — the object already exists by the time the binder sees it.