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

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

Closed
davidmelia opened this Issue May 12, 2018 · 11 comments

Comments

Projects
None yet
8 participants
@davidmelia
Copy link

davidmelia commented May 12, 2018

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

This comment has been minimized.

Copy link
Member

wilkinsona commented May 12, 2018

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

This comment has been minimized.

Copy link

davidmelia commented May 12, 2018

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

This comment has been minimized.

Copy link
Member

wilkinsona commented May 14, 2018

That additional description is very useful. Thank you.

@jpopadak

This comment has been minimized.

Copy link

jpopadak commented May 15, 2018

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

@mbhave mbhave added this to the 2.0.3 milestone May 16, 2018

@mbhave mbhave self-assigned this May 16, 2018

@philwebb philwebb self-assigned this May 21, 2018

@philwebb

This comment has been minimized.

Copy link
Member

philwebb commented May 21, 2018

assigning myself to review this fix

@vivekasingh

This comment has been minimized.

Copy link

vivekasingh commented Jun 4, 2018

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

This comment has been minimized.

Copy link

vivekasingh commented Jun 15, 2018

@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

This comment has been minimized.

Copy link
Member

philwebb commented Jun 15, 2018

@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

This comment has been minimized.

Copy link

vivekasingh commented Jun 18, 2018

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

@PaulGobin

This comment has been minimized.

Copy link

PaulGobin commented Oct 15, 2018

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

This comment has been minimized.

Copy link
Member

philwebb commented Oct 15, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment