Files

Ankur Mhatre 86246dc860 Three new article modules: configuration binding, profiles and config data, Spring AOP

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

2026-09-08 16:47:48 +00:00

2.9 KiB

Raw Blame History

Spring Boot profiles, config import and config trees

Companion project for Spring Boot Profiles Done Right on ankurm.com.

The question the project answers: you set a value in application-prod.yaml, deployed with prod active, and the old value is still in effect. Why?

Versions


Spring Boot	4.1.1
Spring Framework	7.0.9
JDK	Eclipse Temurin 25.0.4.1 (LTS)

Quickstart

export JAVA_HOME=/path/to/jdk-25
mvn -DskipTests package
./scripts/run-all.sh          # regenerate every transcript in docs/output/
mvn test                      # 6 contract tests

Profiles

Profile	What it demonstrates
`prod`	a profile group expanding to `prod`, `prod-db`, `prod-metrics`
`import`	`spring.config.import`, and the imported file winning
`multidoc`	one file, three documents, activated by condition
`badactivation`	`spring.profiles.active` set from a profile-specific document — refused
`staging`	the conditional document inside `application-multidoc.yaml`

Endpoints

Endpoint	Purpose
`GET /precedence?name=`	every source holding a property, ranked, with file and line
`GET /sources`	the live property-source stack in precedence order

Diagnostics. Delete before shipping, or use Actuator's /actuator/env, which sanitises.

Documentation

Captured output

File	Produced by
`00-versions.txt`	`scripts/demo-versions.sh`
`01-precedence.txt`	`scripts/demo-precedence.sh`
`02-profile-file-loses.txt`	`scripts/demo-profile-file-loses.sh`
`03-config-tree.txt`	`scripts/demo-config-tree.sh`
`04-import-and-multidoc.txt`	`scripts/demo-import-and-multidoc.sh`

The short answer

Config data — every file you write, profile-specific ones included — is item 3 in Spring Boot's documented precedence list. OS environment variables are item 5. Later items win. A profile-specific file beats other files and loses to the weakest environment variable on the host.

The one that surprises people

spring.config.import does not behave like #include. The imported file is processed after the file that declared the import, so it wins. Import a shared baseline expecting to override it and every key it sets will quietly beat yours.

2.9 KiB Raw Blame History