Different profile precedence introduced in Spring Boot 2.0.2 - include profile now comes after active.

[davidmelia]

Hi,

Spring Boot 2.0.2 has introduced a different profile precedence when compared to previous versions.

It's very easy to reproduce.

1. In STS create a Spring boot starter web project
2. In the application.properties add spring.profiles.include=include
3. Build and run the project with java -jar ./target/somename-0.0.1-SNAPSHOT.jar --spring.profiles.active=active
4. You will see The following profiles are active: active,include which is incorrect

Downgrade the pom to Spring boot 2.0.1 and run again and you will see
The following profiles are active: include,active
which is correct

Spring boot 1.5.13 also gives The following profiles are active: include,active

I'm using Java 8 & MacOS High Sierra.

Thanks

[wilkinsona]

See #11380, part of which corrected the ordering of the logged profiles to accurately reflect the order in which they were processed.

You will see The following profiles are active: active,include which is incorrect

Can you please explain why you consider this to be incorrect?

spring.profiles.active is a command line argument so it’s seen first and active is made active. application.properties is then read at which point include is made active. Given this ordering active,include would seem to be correct.

[davidmelia]

Hi,

If I explain my use case:

I'm deploying in a microservice architecture so I've created a common microservices maven dependency containing spring boot properties I want across all Microservices:
application-microservice.properties
and also contains a common override when I deploy to the cloud
application-cloud.properties

Every microservice pulls in this maven dependency & switches on the first profile via
spring.profiles.include=microservice
in the local application.properties of that service.

When I deploy to the cloud I additionally add the command line argument
--spring.profiles.active=cloud
which turns on the override.

What's happening now is the cloud profile property is being overridden by the microservice profile and therefore Spring Boot 2.0.2 is quite a large breaking change for me.

To illustrate this further if I have a spring boot app with the following properties

application-cloud.properties
    some.key=cloudprop
application-microservice.properties
    some.key=microserviceprop
application.properties
    spring.profiles.include=microservice

and a command line active profile of 'cloud' then Spring Boot <=2.0.1 outputs 'cloudprop' where as 2.0.2 outputs 'microserviceprop'

Thanks

[wilkinsona]

That additional description is very useful. Thank you.

[jpopadak]

I seem to be having the exact same issues. Anything in include is overriding my active profile.

[philwebb]

assigning myself to review this fix

[vivekasingh]

I have similar experience too. My services get configuration from config server and the order of profile in http request is changed.
For example:
Spring Boot 2.0.1: http://localhost:8080/config/fooservice/mysql,native
Spring Boot 2.0.2: http://localhost:8080/config/fooservice/native,mysql

[vivekasingh]

@philwebb I still the issue with Spring Boot 2.0.3, included profiles are still having higher priority than active profile.

I have a bootstrap.yml into classpath which tries to include a profile, and while start the application I am passing the active profile. When properties are fetched from config service, its giving higher priority to profile being included into bootstrap.yml file.

[philwebb]

@vivekasingh I tested with the example given in #13151 (comment). Perhaps it's related to the use of bootstrap.yml. Can you please open a new issue with a sample that we can run?

[vivekasingh]

Thanks @philwebb Just opened #13513 with sample project to demonstrate the issue.

[PaulGobin]

on a similar note for Kubernetes ConfigMap, I have the following in bootstrap.yml

  cloud:
    kubernetes:
      reload:
        enabled: true
        mode: polling
        period: 5000
      secrets:
        enable-api: false
        enabled: false  
      config:
        enable-api: true
        enabled: true
        sources:
          - name: ${spring.application.name}
          - name: common
          - name: common-sqlserver
          - name: common-doc

Output in console:

Located property source: CompositePropertySource {name='composite-configmap', propertySources=[ConfigMapPropertySource {name='configmap.common-doc.default'}, ConfigMapPropertySource {name='configmap.common-sqlserver.default'}, ConfigMapPropertySource {name='configmap.common.default'}, ConfigMapPropertySource {name='configmap.we-order-service.default'}]}

I am thinking the ordering should be top down vs bottom up?

[philwebb]

@PaulGobin bootstrap.yml is a Spring Cloud concern. If you think you've found an issue please report it at https://github.com/spring-cloud/spring-cloud-commons/issues and provide a small sample that shows the problem.

[kapad]

@philwebb @mbhave

Sorry to be commenting here on an old issue, but my company is using a rather old version of spring-boot (1.5.6.RELEASE) and I'm not sure if this same bug existed in that version or not.

I seem to facing the same problem, where a profile included using spring.profiles.include overrides properties that it shouldn't be as per the documentation.

The problem that I am facing is

application-dev.yml

spring:
  profiles:
    include: 
      - 'main-dev'

flyway:
  enabled: true
  location: 'migrations'

application-main-dev.yml

flyway:
  enabled: false

When I run with -Dspring.profiles.active=dev my console prints the active profiles as main-dev, dev, which seems correct. What I expect, is that properties in the dev profile would override properties in the main-dev profile. But the behavior is the exact opposite, and the value that the flyway auto configuration class sees for flyway.enabled is false.

What I was hoping that you could answer for me, is

1. Is there a bug in 1.5.6.RELEASE that is causing this? (I'll then stick to my work around for this)
2. Or is there something that I am doing wrong in the way in which properties files are included?

[philwebb]

@kapad There are a few known issues with property file handling in 1.5.x but we've decided that it's too risky to fix them at this point. On a related note, 1.5.x is EOL in August so you should consider upgrading if possible.

[kapad]

@philwebb thanks for replying to this really old issue. :)

Where can I see the EOL of different spring versions? What you mention is definitely something my team needs to look into, and I would like to link to the official pages and raise the EOL issue to my manager.

[philwebb]

@kapad Announcements are usually made on spring.io/blog. Spring Framework also have a wiki page. We have an open issue to make this information easier to find.

[kapad]

hey @philwebb

So I was going through the dependencies of spring-boot 2.0.x and saw that the spring core version that is required is 5.0.x
Now, my org is using spring-boot 1.5.6 and as you mentioned in an earlier comment, that version of spring boot is reaching EOL on 1st August, 2019.
spring-boot 1.5.6 though, depends on spring-core 4.3.10 (see), which will continue to be maintained until mid-2020 (from the wiki that you shared earlier).
So my question is this -> which version of spring boot should I upgrade to, so that I continue depending on spring-core (and other framework dependencies) of the 4.3.10 LTS version and also continue using a spring boot version that is officially supported?

[wilkinsona]

After 1st August there will not be a supported version of Spring Boot that depends on Spring Framework 4.3.x. If you want to continue to use a supported version of Spring Boot, you should upgrade to 2.1.x.