Comment From: mbhave

We probably won't be able to apply the same rule to profile-specific property files. For example, let's say application.properties has spring.profiles.include=bar and application-bar.properties has spring.profiles.include=baz. In this case, we'd process spring.profiles.include from both sources.

This means that spring.profiles.include would have a cascading behavior for config files combined with the profile-specific config files but the cascading behavior wouldn't apply if spring.profiles.include was specified in a property source higher than the config files.

Comment From: clevertension

@mbhave can you clarify it with more examples? what's the mean of property source? xxx.properties file or -D with jvm arguments?

Comment From: wilkinsona

@clevertension I opened the issue with no description so i’m not sure why you are asking @mbhave to clarify things rather than me. We opened the issue as Madhura and I identified a bug while reviewing another change. It’s a tricky problem and the issue was opened as a reminder to us more than anything else. Madhura’s comment means that it’s not as easy to fix as we had hoped.

A property source is a Spring Framework concept that is described in some detail in its javadoc.

Comment From: clevertension

oh, i just want to know more about 1. why spring.profiles.include in the config files should be ignored when spring.profiles.include is set in a property source with higher precedence than the config files

  1. why the cascading behavior wouldn't apply if spring.profiles.include was specified in a property source higher than the config files?

you can ignore this reply if the reason is too complex to explain :blush:

Comment From: wilkinsona

  1. why spring.profiles.include in the config files should be ignored when spring.profiles.include is set in a property source with higher precedence than the config files

Because property sources are documented as being considered in order of precedence. Once a property is found in a particular source, the same property in sources with lower precedence should be ignored.

2. why the cascading behavior wouldn't apply if spring.profiles.include was specified in a property source higher than the config files?

Because spring.profiles.include in the config files will be ignored once it has been set in a property source with higher precedence.

Comment From: wilkinsona

We probably won't be able to apply the same rule to profile-specific property files. For example, let's say application.properties has spring.profiles.include=bar and application-bar.properties has spring.profiles.include=baz. In this case, we'd process spring.profiles.include from both sources.

I'm finding it hard to know what the most intuitive behaviour should be here.

On the one hand, spring.profiles.include=baz should take precedence over spring.profiles.include=bar and only baz should be active. On the other hand, if only baz was active, application-bar.properties should not be considered so only bar should be active.

I can think of two options which I think could be explained and justified:

  1. When considering property sources in order of precedence, once we encounter spring.profiles.include for the first time, any subsequent spring.profiles.include property will be ignored. This means that a spring.profiles.include property in property-specific configuration file will be ignored if it was only processed due to a spring.profiles.include in the main configuration file.
  2. Due to the main configuration file being able to activate profiles and, therefore, trigger the addition of property sources with higher precedence, spring.profiles.include in configuration files is given special treatment and the values are combined across all configuration files. @mbhave, I think this is the behaviour you've described above.

Comment From: wilkinsona

spring.profiles.default is another complicating factor (#15994).

Comment From: clevertension

in my opinion, we can have a notation that spring.profiles.include is a special property that it will merge instead of overwrite the values in property source or config files, and then it will load all the profile-specific config files as application-{values} with YAML or properties

Comment From: clevertension

in org.springframework.core.env.AbstractEnvironment, we can see both spring.profiles.active and spring.profiles.default to get property value, but in the spring boot org.springframework.boot.context.config.ConfigFileApplicationListener, it only handle the spring.profiles.active, so i think we should load config file with spring.profiles.default in spring boot

Comment From: mbhave

Due to the main configuration file being able to activate profiles and, therefore, trigger the addition of property sources with higher precedence, spring.profiles.include in configuration files is given special treatment and the values are combined across all configuration files. @mbhave, I think this is the behaviour you've described above.

Yeah, this is what I tried to describe above. I think I prefer this option to 1 because that's how I've seen quite a few people use spring.profiles.include. See #13299 and some of our tests that showcase the cascading behavior. That being said, I think it might be confusing that the spring.profiles.include property from config files is treated differently.

Adding for: team-attention to discuss this on the team call.

Comment From: wagnerluis1982

Hi, if possible I wanted to assign myself to this issue.

But before I wanted to understand the desired behavior with some examples (please, make me know about any error on my analysis):

Say I have the following:

# application.properties
spring.profiles.include=main

# application-animal.properties
spring.profiles.include=lion

# application-fruit.properties
spring.profiles.include=apple

Profiles activation scenarios: 1. Not informing any profile: I expect main profile to be active. 2. spring.profiles.active=animal: I expect animal, main and lion profiles to be active. 3. spring.profiles.active=fruit: I expect that fruit, main and apple profiles to be active. 4. spring.profiles.active=inexistent: I expect inexistent and main profiles to be active.

Profiles include scenarios: 1. spring.profiles.include=animal: I expect only animal and lion profiles to be active (main profile is overridden).

  1. spring.profiles.active=animal and spring.profiles.include=fruit: This is trickier, since we are not only overriding include from default properties file, but also from animal file.

    So, I expect to be active only animal, fruit and apple profiles.

  2. spring.profiles.active=animal and spring.profiles.include=inexistent Similar to the previous scenario, but I'm including a profile that has no properties file.

    At this one, I expect to be active only animal an inexistent profiles.

Phew, to conclude this "essay" I wanted to get how spring.profiles.default fit at this.

Comment From: mbhave

Thank you for the offer to help @wagnerluis1982. The code related to processing profile-specific property files is quite complex and we've realized that it's probably going to need an overhaul to fix a lot of these issues. I think we should wait to fix this and tackle it along with the others.

Comment From: wagnerluis1982

I think we should wait to fix this and tackle it along with the others.

Oh, I see... I will check these other issues, thank you!

Comment From: mbhave

I think this issue has been superseded by the recent profiles related work in 2.4.x.