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
2.4 KiB
1. The precedence list
Spring Boot's documented order, lowest precedence first. Later entries win.
| # | Source |
|---|---|
| 1 | Default properties (SpringApplication.setDefaultProperties) |
| 2 | @PropertySource on @Configuration classes |
| 3 | Config data — application.properties, application.yaml, profile-specific files, spring.config.import |
| 4 | RandomValuePropertySource (random.*) |
| 5 | OS environment variables |
| 6 | Java system properties (-D) |
| 7 | JNDI attributes from java:comp/env |
| 8 | ServletContext init parameters |
| 9 | ServletConfig init parameters |
| 10 | SPRING_APPLICATION_JSON |
| 11 | Command-line arguments |
| 12 | properties on @SpringBootTest |
| 13 | @DynamicPropertySource |
| 14 | @TestPropertySource |
| 15 | Devtools global settings |
The two rows that matter
Item 3 covers every file you write. application.yaml, application-prod.yaml, an
imported config tree, a mounted ConfigMap — all of it is config data, all of it at rank 3.
Item 5 is above it. Every environment variable outranks every file.
Profile-specific files beat non-profile files, and later imports beat earlier ones, but those are orderings within item 3. Nothing inside item 3 can reach item 5.
That single fact explains the bug this project exists for, and chapter 4 walks through it with a transcript.
Seeing it for real
/sources prints the live stack, which is more useful than the table because it shows exactly
which files were loaded:
3. SimpleCommandLinePropertySource commandLineArgs
6. PropertiesPropertySource systemProperties
7. OriginAwareSystemEnvironmentPropertySource systemEnvironment
9. OriginTrackedMapPropertySource application-prod-metrics.yaml
10. OriginTrackedMapPropertySource application-prod-db.yaml
11. OriginTrackedMapPropertySource application-prod.yaml
12. OriginTrackedMapPropertySource application.yaml
Note rank 2 in the real stack, which the table does not mention:
ConfigurationPropertySourcesPropertySource, named configurationProperties. That is the
source Spring Boot attaches to give ${...} placeholders the binder's relaxed name matching —
see the binding project's chapter 2.