SpringProfileDocumentMatcher does not work as expected

[michael-simons]

The following issue appears with Spring Boot 1.4.3:

Given a YAML configuration like

someValue: 4711

example:
    greeting: Hello, World!
---
spring:
    profiles: demo1
example:
    greeting: Hello, Demo1!

---
spring:
    profiles: demo2
example:
    greeting: Hello, Demo2!

---
spring:
    profiles: "!demo2"
someValue: 2109

(Full configuration and properties class in example project extconfig see: application.yml and ExampleConfiguration)

and run with java -jar target/extconfig.jar I expect someValue to be 2109: The negated profile !demo2 overwriting the value of 4711.

run with java -jar target/extconfig.jar --spring.profiles.active=demo2 I expect someValue to be 4711 as it is set in the default, not overwritten in demo2 (not set) and not overwritten bei !demo2. The same is expected for the other parts of the configuration.

In contrast to my expectations, I get in both cases 2109.

The project linked above contains a test class NegatedProfilesTest that fails.

[wilkinsona]

@michael-simons and I discussed this a bit already. The problem appears to be that SpringProfileDocumentMatcher isn't correctly configured with the active profiles. Instead, it only considers a profile to be active if it's processing a configuration file that's specific to that profile.

[mbenson]

I've attacked this a couple of ways and it seems a pretty tough nut to crack within the confines of the existing PropertySourcesLoader/PropertySourceLoader API. I don't have anything helpful yet, but anything that can get folks thinking about the problem. The SpringProfileDocumentMatcher works pretty well in a vacuum. :|

[mbenson]

Okay, on my third attempt I have some code that seems to be working. I'm not submitting a PR just yet because I think my approach is invasive enough that it bears discussion, but as I said it's not a simple problem to solve within the confines of the existing APIs: https://github.com/mbenson/spring-boot/tree/yaml-negation

[mbenson]

Over the weekend it occurred to me that it was only sensible to handle spring.profiles.include in this code as well. After a bit of work I came to the conclusion that it was necessary to determine the active profile information in a first pass before coming back to actually load the profile-specific subdocuments; the branch referenced above now reflects this.

[mbenson]

I thought of another way to break the code I had in place, e.g.:
application.yml:

spring.profiles:
  - "!foo"

application-bar.yml

spring:
  profiles:
    include:
      - foo

My branch https://github.com/mbenson/spring-boot/tree/yaml-negation now accounts for this case, whenever the team is ready for a discussion. :)

[michael-simons]

Thanks @mbenson for your work on this!