Conditional documents in profile specific file are not loaded consistently

I’ve following problem.

I’ve an instance with following active profiles: dev, test, foo

and apllication-test.yaml file

---
my.prop1: default
my.prop2: default
---
spring.profiles: dev
my.
    prop1: dev
    prop3: abc
---
spring.profiles: foo
my.prop2: foo

My intuition would tell me: my.prop1 = dev my.prop2 = foo

Thought the result is really: my.prop1 = default my.prop2 = foo

It seems to use the order of profiles, rather then the order of the document. This seems to be different then what the documentation is saying. (Correct me if I’m wrong)

Further more my.prop3 seems to be not set at all as if this section is ignored even if dev is set active.

Is this a bug of Spring or is there a trick to it?

lG Lukas

[shakuzen]

I also ran into this problem and it took quite some time to track it down and figure out why it was happening. My use case is that we have configuration properties specific to logical environments (say dev, stg, prod) and that we want to be active only when the application is running on our platform (Cloud Foundry as cloud profile; or our other platform that uses the server profile) as opposed to a developer’s machine. The assumption being a developer might activate a logical environment profile from her or his machine but would not activate cloud or server.

Therefore, to achieve this, it seemed reasonable to me to put say the DEV environment spring.boot.admin.client.uri in a file application-dev.yml like:

---
spring:
  profiles: cloud,server

  boot.admin.client.uri: http://my-admin-url

The above works fine, actually, if the active profiles are in the “right” order dev,cloud, but it does not work if the order is cloud,dev. This can also be demonstrated by the following change to an existing Spring Boot test (switch the order of the active profiles):

===================================================================
--- spring-boot-project/spring-boot/src/test/java/org/springframework/boot/context/config/ConfigFileApplicationListenerTests.java	(revision 3ae4a541b630fb7bccf45ebd0922c19d099c2276)
+++ spring-boot-project/spring-boot/src/test/java/org/springframework/boot/context/config/ConfigFileApplicationListenerTests.java	(date 1521006994000)
@@ -777,7 +777,7 @@
 		SpringApplication application = new SpringApplication(Config.class);
 		application.setWebApplicationType(WebApplicationType.NONE);
 		this.context = application.run(
-				"--spring.profiles.active=activeprofilewithdifferentsubdoc,activeprofilewithdifferentsubdoc2");
+				"--spring.profiles.active=activeprofilewithdifferentsubdoc2,activeprofilewithdifferentsubdoc");
 		String property = this.context.getEnvironment().getProperty("foobar");
 		assertThat(property).isEqualTo("baz");
 	}

https://github.com/spring-projects/spring-boot/blob/3ae4a541b630fb7bccf45ebd0922c19d099c2276/spring-boot-project/spring-boot/src/test/java/org/springframework/boot/context/config/ConfigFileApplicationListenerTests.java#L774-L783

I’ve also pushed a repro project with a failing test case: https://github.com/shakuzen/demo-compound-profile

To summarize the use case, being able to use sub-documents in YAML files that are themselves profiled allows for AND semantics. In the example shown above, the dev profile AND the cloud (OR server) profile should be active for the property source to be included. #12469 was raised recently also regarding AND profile matching semantics. What I find nice about what I expected to work (and does if the active profile order is “right”) is that it allows one AND and an arbitrary number of ORs. Perhaps the outcome of SPR-12458 will pave a way for something more robust.

For my specific use case mentioned above, we can work around this thanks to Spring Boot Admin client offering an enabled property that we can set to false by default and only make it true when the cloud OR server profile is active. Perhaps there are other use cases that aren’t as easily worked around. At the least, the behavior was hard to understand and surprising.

[mbhave]

This should be solved by config data rewrite in 2.4.x. For multi-document files, later documents can override the properties defined in earlier ones. With the following configuration in application-test.yml and active profiles of dev, foo, test,

---
my.prop1: default
my.prop2: default
---
spring.profiles: dev
my.
    prop1: dev
    prop3: abc
---
spring.profiles: foo
my.prop2: foo

the result is

my.prop1 = dev my.prop2 = foo my.prop3 = abc