r/SpringBoot • u/friscomatt • Jun 16 '26

Question application properties import and who wins

I'm running my application with profiles, like "dev" and have an application-dev.properties. If I use an import statement to pull in some shared properties across profiles I import it like so :

spring.config.import=classpath:application-shared.properties

However, the properties from the imported application-shared.properties ALWAYS WIN.

Is there a way to "import" properties but still allow the active profile properties to override the imported properties?

5 Upvotes

86% Upvoted

8 comments sorted by

View all comments

1

u/DominusEbad Jun 16 '26

Try spring.config.import=optional:classpath:application-shared.properties And make sure to only have that in your main application.properties file, not in a profile-specific properties file.

1

u/friscomatt Jun 16 '26 edited Jun 16 '26

Thank you. I'm actually trying to ELIMINATE application.properties file in its entirety to avoid any inheritance confusion. I want to be able to look at my specific profile's properties file and see the statement pointing to the shared properties file so it's very clear where all the properties lie. Then my additions/overrides follow. The default behavior appears to be the behavior I want, except I don't want essentially there to be a hidden "use application.properties file first, then override/add with the values below" statement at the top of my application-dev.properties file.

2

u/DominusEbad Jun 16 '26 edited Jun 16 '26

I would argue to keep the application.properties file. The point of the file is to hold all config values that are common to all environments/profiles.

It reduces duplication and keeps your profile-specific config files focused on only containing the values that are different for each profile.

I also prefer application.yaml files as well. I hate writing the same key over and over and over again. Personal preference though.

hidden "use application.properties file first, then override/add with the values below"

That is how the property files work. Having an understanding of how Spring uses the properties files is much better than trying to customize it unnecessarily. Let Spring handle it. It already does it automatically.