Relative spring.config.import in a file found through a wildcard location resolves against the pattern and imports files from sibling directories

Aperta
  • Qualcosa non va?
#52,648 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
79/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, spring-boot
Ambito
backend

Direzione di ricerca

Start with StandardConfigDataLocationResolver#getResourceLocation and its existing tests in StandardConfigDataLocationResolverTests; the issue identifies how the wildcard pattern becomes the parent directory. Reproduce with the config/a and config/b layout described, then check that the import from config/a/application.yaml resolves only config/a/other.yaml. The issue reports that the resolver and integration test suites pass with a proposed change; add a regression test for this case.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

status: waiting-for-triage

The reference documentation says that a relative spring.config.import "is resolved relative to the file that declares it". When the declaring file was found through a wildcard location (for example spring.config.location=optional:file:./config/*/), the parent directory is computed from the pattern, not from the concrete file.

StandardConfigDataLocationResolver#getResourceLocation uses resource.getReference().getResourceLocation(), which is file:./config/*/application.yaml. The parent directory therefore becomes file:./config/*/, and the import is itself resolved as a wildcard across every sub-directory.

Spring Boot 4.1.2

config/a/application.yaml   -> spring.config.import: other.yaml
config/a/other.yaml         -> owner: dir-a
config/b/other.yaml         -> owner: dir-b        (no application.yaml in b)

java -jar app.jar --spring.config.location=optional:file:./config/*/
environment.getProperty("owner")  ->  "dir-b"     (expected "dir-a")

Both config/a/other.yaml and config/b/other.yaml are imported, and the file from the unrelated directory b wins. This is surprising with the common Kubernetes layout where several ConfigMaps/Secrets are mounted under config/*/: a file from one mount can silently override values imported by another.

Possible fix: when the parent reference location is a pattern, derive the directory from the concrete resource:

private String getParentDirectory(StandardConfigDataResource resource) {
	String location = resource.getReference().getResourceLocation();
	if (this.resourceLoader.isPattern(location)) {
		location = getUrl(resource.getResource());
	}
	return location.substring(0, location.lastIndexOf("/") + 1);
}

I verified this end to end by running the packaged app as a separate process and reading the property over HTTP. With 4.1.2 the result is dir-b; with a locally built spring-boot jar including the change above, it is dir-a. The existing StandardConfigDataLocationResolverTests and ConfigDataEnvironmentPostProcessorIntegrationTests still pass. I'm happy to submit a PR with a test.

Lingua principale
Java
Stelle
81.8k
Fork
43.5k
Merge medio
3g 13h
PR unite (30g)
89

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di spring-projects/spring-boot

Tutte le issue di spring-projects/spring-boot

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.