Spring "spring.profiles.include" overrides
Spring Boot 2.4 changes the mechanism for including multiple profiles to use a new profile groups feature, rather than using spring.profiles.include
within the profile-specific document. This means that your configuration is no longer valid for new versions of Spring Boot, and would need to be changed.
That said, your use case does not seem to be a great fit for profile groups, as it's not really combining two profiles so much as overriding defaults. Therefore, I recommend using the approach suggested in another answer of putting the common and default properties in a shared application.yaml
file, and only including the environment-specific values & overrides in the profile-specific documents.
application.yaml
spring:
myproperty: 44 # Default value
application-bar.yaml
spring:
myproperty: 55 # Override default
Note that Spring Boot supports multi-document files, so these can be combined into a single application.yaml
file if desired:
spring:
myproperty: 44 # Default value
---
spring.config.activate.on-profile: bar # These configs apply to the bar profile
spring:
myproperty: 55 # Override default
Relevant 2.4 Changes
It is no longer possible to use spring.profiles.include
within a profile-specific document as of Spring Boot 2.4, unless legacy mode is enabled using spring.config.use-legacy-processing=true
. Per the 2.4 Spring Boot Config Data Migration Guide:
you can still use the spring.profiles.include property, but only in non profile-specific documents.
This approach has been replaced by the profile groups feature. Per the migration guide:
As discussed above, it’s no longer possible to use
spring.profiles.include
in a profile-specific document so this file isn’t valid.Since this use-case is quite common, we’ve tried to provide another way to support it. In Spring Boot 2.4 you can use the “profile groups” feature.
This feature is documented in the Profile Groups section of the Spring Boot reference guide:
A profile group allows you to define a logical name for a related group of profiles.
For example, we can create a
production
group that consists of ourproddb
andprodmq
profiles.spring: profiles: group: production: - "proddb" - "prodmq"
Our application can now be started using
--spring.profiles.active=production
to active theproduction
,proddb
andprodmq
profiles in one hit.
The migration guide points out that the spring.profile.group
property cannot be used in profile-specific documents.
The
spring.profile.group
property cannot be used in profile-specific documents.
We implemented the Spring active profiles in a slightly different way. Let's say the default properties file, application.yml
, contains all default values which is same in both production and development environments.
Create separate properties for production and development files named application-prd.yml
and application-dev.yml
respectively. These files may contain extra properties or override some of the default properties.
During application startup, we pass the spring.profiles.active
as an environment variable. For example,
-Dspring.profiles.active=prd
will pick up application-prd.yml
along with application.yml
or
-Dspring.profiles.active=dev
will pick up application-dev.yml
along with application.yml
According to the spring boot documentation here, spring.profiles.include
is used to add the properties from other profiles. It will add the property from other profiles if the property is not present in active one. But if it is present, then it will overwrite and the last one to be applied wins
Sometimes, it is useful to have profile-specific properties that add to the active profiles rather than replace them. The
spring.profiles.include
property can be used to unconditionally add active profiles.
You could add a new profile in the application-bar.yaml
:
spring.profiles.include: foo,foo-override
myproperty: 33
---
spring.profiles: foo-override
myproperty: 55
The order is: 33 in bar
overridden by 44 in foo
overridden by 55 in foo-override
.