Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify precedence between yml and properties files on the same level #25121

Closed
leonard84 opened this issue Feb 5, 2021 · 3 comments
Closed
Labels
status: superseded An issue that has been superseded by another type: documentation A documentation update

Comments

@leonard84
Copy link
Contributor

In 4.2. Externalized Configuration (Spring Boot 2.4.2) it states that

Config data files are considered in the following order:

  1. Application properties packaged inside your jar (application.properties and YAML variants).
  2. Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants).
  3. Application properties outside of your packaged jar (application.properties and YAML variants).
  4. Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants).

However, what is unclear is which config values wins if you have both application.yml and application.properties on the same level. We'd like to use Variant 1 (see below), which seems to work, but relies on undocumented behavior that could easily change, so it would be great if the precedence handling could be added to the docs and checked with tests, if that is not already the case.

Context:

In SB <2.4 we used:

  • src/main/application.yml to store profiles
  • src/main/application-default.properties to set spring.profiles.include=stage-workstation to activate a profile if nothing was activated via ENV/systemproperty. (We used the properties file as this key is invalid in yml, but using this file makes it also easy to override for test)
  • src/test/application-default.properties to set spring.profiles.include=stage-workstation, test to activate the test profile
  • src/main/application-test.yml with profile in the name to avoid overriding the application.yml

For SB 2.4.x

We are evaluating two solutions

Variant 1

  • src/main/application.yml to store profiles and use spring.profiles.group.default=stage-workstation
  • src/test/application.properties to set spring.profiles.group.default=stage-workstation,test to activate the test profile and use properties instead of yml to avoid overriding the application.yml
  • src/main/application-test.yml with profile in the name to avoid overriding the application.yml

Variant 2

  • src/main/application.yml to store profiles and use spring.profiles.group.default=stage-workstation
  • src/test/application.yml that uses spring.config.import=file:${user.dir}/src/main/resources/application.yml and overrides the spring.profiles.group.default=stage-workstation,test (IMHO it is rather brittle to rely on ${user.dir} to be set to the correct location)
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 5, 2021
@philwebb
Copy link
Member

philwebb commented Feb 5, 2021

See #24719 for a recent regression where the order did change between Boot 2.3 and 2.4. Although it's still undocumented, we do at least now have a test.

@philwebb philwebb added the for: team-attention An issue we'd like other members of the team to review label Feb 5, 2021
@mbhave mbhave changed the title Clarify precedence between yml and properties fiels on the same level Clarify precedence between yml and properties files on the same level Feb 5, 2021
@mbhave
Copy link
Contributor

mbhave commented Feb 8, 2021

The reason I think this isn't documented is because we thought people might stick with one format (either .yml or .properties) and not combine both. The use case described above is interesting because it lets you override spring.profiles.group since that is no longer allowed in profile-specific file. I think we should document that .properties will win in such a scenario.

@philwebb philwebb added type: documentation A documentation update and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels Feb 10, 2021
@philwebb philwebb added this to the 2.4.x milestone Feb 10, 2021
@snicoll
Copy link
Member

snicoll commented Mar 1, 2021

Closing in favor of PR #25300

@snicoll snicoll closed this as completed Mar 1, 2021
@snicoll snicoll removed this from the 2.4.x milestone Mar 1, 2021
@snicoll snicoll added the status: superseded An issue that has been superseded by another label Mar 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another type: documentation A documentation update
Projects
None yet
Development

No branches or pull requests

5 participants