New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SpringProfileDocumentMatcher does not work as expected #8011
Comments
@michael-simons and I discussed this a bit already. The problem appears to be that |
I've attacked this a couple of ways and it seems a pretty tough nut to crack within the confines of the existing |
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 |
Over the weekend it occurred to me that it was only sensible to handle |
I thought of another way to break the code I had in place, e.g.:
My branch https://github.com/mbenson/spring-boot/tree/yaml-negation now accounts for this case, whenever the team is ready for a discussion. :) |
Thanks @mbenson for your work on this! |
You're welcome--Having been AFAIK the first person who requested/PR'd the YAML profile negation feature, I did feel responsible. Hopefully this gives the team enough to go on to bang out a solution they are comfortable with. |
@mbenson will your PR also fix the issue with spring:
profiles:
include: workstation
active: local which should only activate This would be better but it seems to be not possible in YAML spring:
profiles: local
include: workstation |
I don't agree that your first example should behave as you describe. I read this as activating
|
@mbenson with my first example I'm referring to http://stackoverflow.com/a/34699686/2145769 which gives a false solution it seems. Your "trick" might work, but it is more a hack than a good solution at least from a DX perspective. IMHO there should be another property to denote profiles in multi-doc YAML file that works for this case, e.g., spring:
profiles:
ids: local
include: workstation |
Certainly it would take a member of the Spring (Boot) team to decide to honor some other property for this purpose. Also, I'm not sure to what "DX" refers. |
DX=developer experience And sure the Spring (Boot) team would have to agree to a change. |
Does not make sense to have in the book as long as spring-projects/spring-boot#8011 is open.
@wilkinsona / @philwebb as Spring 2.0 is on the horizon this would be an ideal way to straighten out the kinks of the profile handling, since it would be a breaking change (small changes required but still). |
Documenting this feature misleads users into thinking it should work. The documentation can be added back once spring-projectsgh-8011 is fixed.
@mbenson thanks for your work on this. Would you like to contribute a PR with the suggested approach of adding another property source if negated profiles are present? I wonder if it's possible to have just one property source corresponding to the negated profile. The code in the branch seems to add the same |
@mbhave I will try to take a look at that this week and get back up to speed. Thanks for the attention! |
I've fixed this in a slightly different way in the end (at least I think it's fixed). The The reason for this is that on the first call, there are no profiles set. This means that any negative sections will match. So given this file: spring:
profiles:
active:
- A
- B
+---
spring.profiles: "!A"
not-a: true You will get a I think that's actually pretty consistent with other yaml loading that we do and I prefer it to checking for active profiles when properties are resolved. For the sake of simplicity, I think we should live with that restriction. |
The following issue appears with Spring Boot 1.4.3:
Given a YAML configuration like
(Full configuration and properties class in example project extconfig see: application.yml and ExampleConfiguration)
and run with
java -jar target/extconfig.jar
I expectsomeValue
to be 2109: The negated profile !demo2 overwriting the value of 4711.run with
java -jar target/extconfig.jar --spring.profiles.active=demo2
I expectsomeValue
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.
The text was updated successfully, but these errors were encountered: