1
0
Files
spring-boot-demo/configuration-properties/docs/08-diagnosing-a-value.md
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.2 KiB

← IDE metadata · Index

8. Diagnosing a value

Endpoint: BindingDiagnosticsEndpoint.

"The property is set but the application does not see it" is the most common configuration bug, and it is hard for one reason: a value carries no visible provenance. Spring Boot tracks it anyway — every property loaded from a file or a config tree carries an Origin naming the resource and the line.

$ curl -s 'localhost:8080/diag/origin?name=demo.mail.host'
{
  "property": "demo.mail.host",
  "effectiveValue": "smtp.example.com",
  "candidatesInPrecedenceOrder": [
    {
      "source": "OriginTrackedMapPropertySource {name='Config resource ... [application.yaml]'}",
      "value": "smtp.example.com",
      "origin": "class path resource [application.yaml] - 15:11"
    }
  ]
}

Line 15, column 11. Not "somewhere in your configuration".

How it works

for (ConfigurationPropertySource source : ConfigurationPropertySources.get(environment)) {
    ConfigurationProperty property =
            source.getConfigurationProperty(ConfigurationPropertyName.of(name));
    if (property != null) {
        // property.getValue(), property.getOrigin(), source.getUnderlyingSource()
    }
}

Iterating ConfigurationPropertySources.get(...) gives you the sources in precedence order. The first hit is the winner; everything after it exists and lost. A property with several holders is exactly what "my change had no effect" looks like from the inside — and the profiles project is entirely about that case.

Delete it before shipping

This endpoint prints whatever a mounted secret contains. If you want it permanently, put it behind the management port and authentication, or use Actuator's /actuator/env, which does the same job with sanitisation built in.

Without an endpoint

  • --debug prints the auto-configuration report, not property origins.
  • Setting logging.level.org.springframework.boot.context.config=TRACE logs which config data resources were loaded, in order — useful when the question is "was my file read at all".
  • In a test, inject Environment and inspect getPropertySources() directly.