Skip to content

Spring profile expression activate YAML documents should have higher priority than profiles #20038

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

Closed
ddcruver opened this issue Feb 5, 2020 · 3 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@ddcruver
Copy link

ddcruver commented Feb 5, 2020

For would like to have certain YAML documents activate only if two profiles are enabled. At the same time I may define a YAML documents for each Profiles. The desired effect is that YAML document activated by the conditional & of the two profiles should have a higher precedence then single profile YAML documents.

Ex.) If spring.profiles.active=ProfileA,ProfileB, I would like the value of spring.message to be "ProfileA an ProfileB activated!!!"

spring:
  profiles:
    active:
      - ProfileA
      - ProfileB

management:
  endpoints:
    web:
      exposure:
        include: '*'
---

spring:
  profiles: ProfileA & ProfileB

  message: ProfileA and ProfileB activated!!!

---

spring:
  profiles: ProfileA

  message: ProfileA activated!!!

---

spring:
  profiles: ProfileB

  message: ProfileB activated!!!

I would expect the positive profiles in an expression would contribute to the precedence but not anything negative.

For example spring.profiles: ProfileA & ProfileB & !ProfileC I would like this YAML document to have higher precedence then ProfileA and ProfileB. The precedence of ProfileC does not matter because it is activated.

I have attached an example project:
profile-expressions.zip

Reference: https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-external-config-multi-profile-yaml

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 5, 2020
@wilkinsona
Copy link
Member

Thanks for the suggestion but, unfortunately, I don’t think we can implement this. It would break the documented behaviour:

The YAML documents are merged in the order in which they are encountered. Later values override earlier values.

This area of the codebase is one of the most complex and problematic and this documented behaviour has some known issues (see #18199, for example). We will hopefully be able resolve #18199 in due course.

Even if it what’s proposed here was not a breaking change, I think it would be foolhardy to add to the existing complexity to order the documents based on the specificity of their profile expressions. It would be difficult to implement and I think it would be difficult for users to understand. For example, if profile b is active, does a & b or c & b win?

Thanks anyway for the suggestion.

@wilkinsona wilkinsona added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 5, 2020
@ddcruver
Copy link
Author

ddcruver commented Feb 5, 2020

The order in which they occur part confused me because it did not matter where in the YAML file I put the spring.profiles: ProfileA & ProfileB YAML document. It always had lower priority.

Regardless thanks for you time.

I revisited it and a better workaround and maybe a more explicit way would be to setup the profiles like this instead:

spring:
  profiles:
    active:
      - ProfileA
      - ProfileB

management:
  endpoints:
    web:
      exposure:
        include: '*'
---

spring:
  profiles: ProfileA & ProfileB

  message: ProfileA and ProfileB activated!!!

---

spring:
  profiles: ProfileA & !ProfileB

  message: ProfileA activated!!!

---

spring:
  profiles: ProfileB & !ProfileA

  message: ProfileB activated!!!

---

@ddcruver
Copy link
Author

ddcruver commented Mar 25, 2021

As an update it looks like this was implemented (with a different property) in Spring Boot 2.4 https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-Config-Data-Migration-Guide#profile-specific-documents. Thanks all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

3 participants