Skip to content

Internal profile-specific properties override external non-profile-specific properties #2404

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

Closed
axtavt opened this issue Jan 23, 2015 · 4 comments
Labels
type: documentation A documentation update
Milestone

Comments

@axtavt
Copy link

axtavt commented Jan 23, 2015

Consider the following external application.properties:

spring.profiles.active=dev
my.property=external

and the following src/main/resources/application-dev.properties:

my.property=internal

When running the application, my.property will resolve to internal, whereas documentation clearly states that it should not be so:

Spring Boot uses a very particular PropertySource order that is designed to allow sensible overriding of values, properties are considered in the the following order:
...
6. Application properties outside of your packaged jar (application.properties including YAML and profile variants).
7. Application properties packaged inside your jar (application.properties including YAML and profile variants).

@philwebb
Copy link
Member

We might need some clarification in the reference docs as we're not really clear on how profiles effect the ordering. I think that this is actually expected behavior.

Profiles specific config takes precedence over the default config, so in this case the src/main/resources/application-dev.properties profile files will override the external application.properties. If you move my.property=external to an external application-dev.properties I believe that it will work.

@dsyer and @wilkinsona might have more input, but I'm somewhat reluctant to change the current behavior.

@dsyer
Copy link
Member

dsyer commented Jan 29, 2015

That is indeed the expected and intended behaviour (so I am also reluctant to change it).

@philwebb philwebb added the type: documentation A documentation update label Jan 29, 2015
@philwebb
Copy link
Member

We'll leave this as it is but try to improve the docs.

@philwebb philwebb modified the milestones: 1.3.0, 1.2.2 Jan 29, 2015
@zmitrok
Copy link

zmitrok commented Feb 20, 2015

Oh I guess I am yet another one who hit this totally expected behavior expecting the opposite :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: documentation A documentation update
Projects
None yet
Development

No branches or pull requests

4 participants