[spring-projects/spring-boot]当 spring.profiles.include 在属性源中设置的优先级高于配置文件时，应忽略配置文件中的 spring.profiles.include

我们可能无法将相同的规则应用于特定于配置文件的属性文件。例如，假设application.propertieshasspring.profiles.include=bar和application-bar.propertieshas spring.profiles.include=baz。在这种情况下，我们将从spring.profiles.include两个来源进行处理。

这意味着配置文件与特定于配置文件的配置文件相结合将具有级联行为，但如果在高于配置文件的属性源中指定，则spring.profiles.include级联行为将不适用。spring.profiles.include

@mbhave 你能用更多例子来澄清吗？财产来源是什么意思？ xxx.properties 文件或带有 jvm 参数的 -D？

@clevertension 我在没有任何描述的情况下打开了这个问题，所以我不确定为什么你要求@mbhave而不是我来澄清事情。我们以 Madhura 的身份提出了这个问题，我在审查另一个更改时发现了一个错误。这是一个棘手的问题，这个问题的提出主要是为了提醒我们。 Madhura 的评论意味着修复它并不像我们希望的那么容易。

属性源是一个 Spring 框架概念，在其 javadoc中有详细描述。

哦，我只是想了解更多

1. 为什么在优先级高于配置文件的属性源中设置spring.profiles.include时应忽略配置文件中的spring.profiles.include

2. spring.profiles.include如果在高于配置文件的属性源中指定，为什么级联行为不适用？

如果原因太复杂无法解释，你可以忽略这个回复:blush:

因为属性源被记录为按优先顺序考虑。一旦在特定源中找到属性，则应忽略优先级较低的源中的相同属性。

因为spring.profiles.include一旦在具有更高优先级的属性源中设置了配置文件，配置文件将被忽略。

我发现很难知道这里最直观的行为应该是什么。

一方面，spring.profiles.include=baz应该优先spring.profiles.include=bar并且只baz应该主动。另一方面，如果仅baz是活跃的，application-bar.properties则不应该被认为是仅bar应该活跃的。

我可以想到两个我认为可以解释和证明的选项：

1. 当按优先顺序考虑属性源时，一旦我们spring.profiles.include第一次遇到，任何后续spring.profiles.include属性都将被忽略。这意味着spring.profiles.include如果特定于属性的配置文件中的属性仅由于spring.profiles.include主配置文件中的 a 而被处理，则该属性将被忽略。
2. 由于主配置文件能够激活配置文件，因此可以触发具有更高优先级的属性源的添加，因此spring.profiles.include在配置文件中进行特殊处理，并且将所有配置文件中的值组合起来。 @mbhave，我认为这就是您上面描述的行为。

spring.profiles.default是另一个复杂的因素（#15994）。

在我看来，我们可以有一个特殊属性的表示法，它将合并而不是覆盖属性源或配置文件中的值，然后它将像 YAML 或属性spring.profiles.include一样加载所有特定于配置文件的配置文件application-{values}

在 中org.springframework.core.env.AbstractEnvironment，我们可以看到 和spring.profiles.active来spring.profiles.default 获取属性值，但是在 Spring Boot 中org.springframework.boot.context.config.ConfigFileApplicationListener，它只处理 ，所以我认为我们应该在 Spring Boot 中spring.profiles.active加载配置文件spring.profiles.default

是的，这就是我上面试图描述的内容。我想我更喜欢这个选项而不是 1，因为我看到很多人都是这样使用的spring.profiles.include。请参阅#13299 以及我们展示级联行为的一些测试spring.profiles.include。话虽这么说，我认为配置文件中的属性被不同地对待可能会令人困惑。

添加for: team-attention以在团队通话中讨论此问题。

你好，如果可能的话，我想把自己分配给这个问题。

但在我想通过一些示例了解所需的行为之前（请让我知道我的分析中的任何错误）：

假设我有以下内容：

# application.properties
spring.profiles.include=main

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

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

配置文件激活场景：

1. 不通知任何个人资料：我希望main个人资料处于活动状态。
2. spring.profiles.active=animalanimal：我预计main和lion个人资料会处于活动状态。
3. spring.profiles.active=fruit：我希望fruit、main和apple个人资料能够活跃。
4. spring.profiles.active=inexistent：我预计inexistent和main个人资料会很活跃。

配置文件包括场景：

1. spring.profiles.include=animal：我希望只有animal和lion配置文件处于活动状态（main配置文件被覆盖）。

2. spring.profiles.active=animal和spring.profiles.include=fruit：这比较棘手，因为我们不仅覆盖默认属性文件中的包含，还覆盖动物文件中的包含。

   所以，我希望只活跃animal，fruit并且apple配置文件。

3. spring.profiles.active=animal与spring.profiles.include=inexistent 之前的场景类似，但我包含了一个没有属性文件的配置文件。

   在这一次，我希望只活跃animal一个inexistent配置文件。

唷，为了结束这篇“文章”，我想知道spring.profiles.default这方面的适合程度。

感谢您提供帮助@wagnerluis1982。与处理特定于配置文件的属性文件相关的代码非常复杂，我们意识到可能需要进行彻底修改才能解决其中的许多问题。我认为我们应该等待解决这个问题并与其他问题一起解决。

哦，我明白了...我会检查其他问题，谢谢！

我认为这个问题已经被 2.4.x 中最近的配置文件相关工作所取代。