Using a config server, in the application.yml I have defined a group:
# application.yml
spring:
profiles:
group:
dev:
- local
- other
In my application configuration, I'm making use of the other profile:
# my-service.yml
spring:
datasource:
url: jdbc:...
---
spring:
config:
activate:
on-profile: other
some:
other:
setting: true
When running the application with the dev profile, I expected to see the some.other.setting=true property. However, the file seems to be skipped and the property is therefore missing. Looking at the output of the HTTP request to config server, I see that both documents in my-service.yml are returned - the default and the one activated by the other profile.
The issue seems to be that the spring.profiles.group set by the application.yml (coming from the config server) is not being applied before evaluating whether the property file should be activated.
Comment From: nickcaballero
I can work around this by setting spring.config.activate.on-profile=dev,other, but it basically makes the profile group pointless.
Another way to make it work is to remove the spring.config.activate.on-profile and move the properties to a profile specific file, like my-service-other.yml. The config server will still return the file because it correctly expands the profile group.
Comment From: scottfrederick
Thanks for getting in touch. Your issues seem to be specific to the use of Spring Cloud Config, which is a separate project with its own issue tracker. There were some known issues with Spring Cloud 2020.0.0 and Spring Cloud Config 3.0.0 related to profiles, so you might check those and make sure you are using a newer version.
If you can reproduce the issues using just Spring Boot, without Spring Cloud Config, please provide a sample that we can use to test it ourselves and re-open the issue so we can take a look.
Comment From: nickcaballero
Hmm, not sure if this is affecting only properties coming from config server. As I mentioned, the config server is returning all the right property files. However, Spring Boot is the one that's filtering them out based on the active profile. In particular, the code at org.springframework.boot.context.config.ConfigDataProperties#isActive is not config server specific and is responsible for deciding if the property file is active or not.
I'm currently using Spring Boot 2.4.4 and Spring Cloud Config Client 3.0.3.
Comment From: wilkinsona
@nickcaballero In that case, can you please provide the sample that doesn't involve Spring Cloud that Scott requested above?
Comment From: philwebb
I believe this might related to the Spring Clould Config Client ConfigDataLocationResolver. The current code uses resolveProfileSpecific to provide config data. This method is only called after profiles have been resolved so I don't think it can contribute profile groups.
I'm happy to take a look If you're able to replicate it without Spring Cloud. If not, I think the issue should be raised here.
Comment From: nickcaballero
That makes sense. Looks like most of the implementations of the ConfigDataLocationResolver in the Spring Cloud project are doing the same, which would mean that none of them can contribute to the profile groups.
Comment From: philwebb
/cc @spencergibb
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
Comment From: MOS6522
I ran into this problem yesterday and in an environment of mixed Spring Boot 2.7, 3.0, 3,1 and 3.2, with and without the "bootstrap starter", this was a very hard thing to diagnose.
Going to our Configuration Server, we could see all settings the way they have worked for 3 years, all working as usual, but looking at the ENV actuator in our apps, some apps had sections missing. It appeared this was happening mostly in newly updated applications. This ticket turns out to be the issue.
Let's take the following YaML for application.yml:
# applicaiton.yml
spring.profiles.group:
region1: region1
region2: region2,secondary
And then in the region files:
# application-region1.yml
---
spring.config.activate.on-profile: region1
my.setting: primaryValue
---
spring.config.activate.on-profile: secondary
my.setting: secondaryValue
# application-region2.yml
---
spring.config.activate.on-profile: region2
my.setting: primaryValue
---
spring.config.activate.on-profile: secondary
my.setting: secondaryValue
This will fail in the client (server will report correctly). The reason it fails is because all profiles that are NOT listed in the list asked for from the client are deleted in the client. Here, secondary wasn't asked for, so the secondary section is deleted by the client.
A fix is to just make sure the profile sections are the only ones returned. In this case, the fix is fairly simple: just create application-secondary.yml file with "region1" and "region2" sections. To enable ordering, you also need to move the application-region1.yml and application-region2.yml to something like application-region1main.yml. This is what it now looks like:
# applicaiton.yml
spring.profiles.group:
region1: region1main
region2: region2main,secondary
And then in the region files:
# application-region1main.yml
---
spring.config.activate.on-profile: region1
my.setting: primaryValue
# application-region2main.yml
---
spring.config.activate.on-profile: region2
my.setting: primaryValue
---
spring.config.activate.on-profile: region1
my.setting: secondaryValue
---
spring.config.activate.on-profile: region2
my.setting: secondaryValue
Note that the config files have new names just because we want to control the order. If the config files have the same as the profile, then they get included by the normal inclusion logic and they will have a fixed order. By making all of the config files have names that can only be included by group, they only follow the group ordered logic.