The difference between spring.profiles.include and spring.profiles.active

The difference between spring.profiles.include and spring.profiles.active

background

We often see springboot spring.profiles.active, and sometimes we see spring.profiles.includethis configuration, and usually there is spring.profiles.activean additional configuration of include when it exists, so what is the difference?

There is no difference between using spring.profiles.includeand spring.profiles.active. If used together, the order of the final profile is include first, and then active, that is, the key with the same name in active will overwrite the include (the latter has a higher priority), such as

spring.profiles.active=A,B
spring.profiles.include=C,D

In the end this is the orderC,D,A,B

You can refer to the appendix for the official documents. In fact, although the official website is authoritative, it reads dryly. You still have to do an experiment yourself to strengthen your understanding of the description of the official website.

experiment

• application.properties

  spring.profiles.active=dev
  

• application-dev.properties

  common.key=dev
  only.dev=dev
  

• application-prod.properties

  common.key=prod
  only.prod=prod
  

• java code

  @GetMapping("/getValue")
  public String getValue() {
        
        
    String[] activeProfiles = environment.getActiveProfiles();
    String[] defaultProfiles = environment.getDefaultProfiles();
    System.out.println("activeProfiles:" + Arrays.toString(activeProfiles));
    System.out.println("defaultProfiles:" + Arrays.toString(defaultProfiles));
    System.out.println("common.key:" + environment.getProperty("common.key"));
    System.out.println("only.dev:" + environment.getProperty("only.dev"));
    System.out.println("only.prod:" + environment.getProperty("only.prod"));
    return "success";
  }
  

print result

activeProfiles:[dev]
defaultProfiles:[default]
common.key:dev
only.dev:dev
only.prod:null

The content in the above application.properties is changed (not added!)

spring.profiles.include=dev

then print

activeProfiles:[dev]
defaultProfiles:[default]
common.key:dev
only.dev:dev
only.prod:null

spring.profiles.activesame result as

If the content of application.properties is changed to

spring.profiles.active=dev,prod

then print

activeProfiles:[dev, prod]
defaultProfiles:[default]
common.key:prod
only.dev:dev
only.prod:prod

If you change the order of the profile, change it to

spring.profiles.active=prod,dev

then print

activeProfiles:[prod, dev]
defaultProfiles:[default]
common.key:dev
only.dev:dev
only.prod:prod

It can be found common.keythat the value of is changed with the adjustment of the order, and the later profile overrides the previous one

Conclusion: spring.profiles.active=profile1,profile2 This way of writing, when the key is the same, the configuration in the later profile overrides the previous one (different merges together)

spring.profiles.include=profile1, profile2 is also covered by the front? ,have a test:

# 如果 application.properties 的内容改成 spring.profiles.include=dev,prod 时所打印的结果如下
activeProfiles:[dev, prod]
defaultProfiles:[default]
common.key:prod
only.dev:dev
only.prod:prod

# 如果 application.properties 的内容改成 spring.profiles.include=prod,dev 时所打印的结果如下
activeProfiles:[prod, dev]
defaultProfiles:[default]
common.key:dev
only.dev:dev
only.prod:prod

It can be found common.keythat the value of is also affected by the order of the profile

**Conclusion:** spring.profiles.include is the same as spring.profiles.active configuration. When multiple profiles are configured, the key value t'h in the subsequent profile will overwrite the previous one (if the key is the same)

Let's start to study the behavior when two configurations (active and include) exist at the same time . If the content of application.properties is changed to

spring.profiles.active=dev
spring.profiles.include=prod

printed log

activeProfiles:[prod, dev]
defaultProfiles:[default]
common.key:dev
only.dev:dev
only.prod:prod

If you change the location, the content of application.properties is changed to

spring.profiles.active=prod
spring.profiles.include=dev

Then the test result is

activeProfiles:[dev, prod]
defaultProfiles:[default]
common.key:prod
only.dev:dev
only.prod:prod

Conclusion : first put the profile in the include first, and then the active one

If there are multiple values ​​in the active and include configurations, the content of application.properties is changed to the following

spring.profiles.active=dev,profileInActive
spring.profiles.include=prod,profileInInclude

Then the log printed at startup is (the log omits unnecessary information)

The following profiles are active: prod,profileInInclude,dev,profileInActive

It can be further verified , and the final result of the profile will be to take out the include first, and then add the active one. In addition, if the profile does not exist, no error will be reported , and the above profileInInclude and profileInActive do not exist)

appendix

The above is a do-it-yourself experiment, and the following is the official documentation for spring.profiles.includethe explanation

4.3.1. Adding Active Profiles
The spring.profiles.active property follows the same ordering rules as other properties: The highest PropertySource wins. This means that you can specify active profiles in application.properties and then replace them by using the command line switch.

Sometimes, it is useful to have profil-specific properties that add to the active profiles rather than replace them. The spring.profiles.include property can be used to unconditionally add active profiles. The SpringApplication entry point also has a Java API for setting additional profiles (that is, on top of those activated by the spring.profiles.active property). See the setAdditionalProfiles() method in SpringApplication.

For example, when an application with the following properties is run by using the switch, --spring.profiles.active=prod, the proddb and prodmq profiles are also activated:

---
my.property: fromyamlfile
---
spring.profiles: prod
spring.profiles.include:
  - proddb
  - prodmq

https://docs.spring.io/spring-boot/docs/2.2.1.RELEASE/reference/htmlsingle/ 搜 spring.profiles.include

reading notes

• It is mentioned Sometimes, it is useful to have profil-specific properties that add to the active profiles rather than replace themthat there is a wrong word in it, it should be profile-specific
  • First of all, xxx-specific means, for example, "the requirement for the amount of exercise is personal physique-specific", which means that it will vary according to the individual's physique. Simply put, it varies from person to person. So xxx-specific means that it will be different according to the difference of xxx
  • The meaning of this sentence, I understand that sometimes we have some properties (actually key, such as the common.key above), the profile in the include can be added to the profile configured in the active, instead of replacing (meaning It should be that the include profile is placed in front of the active profile, so the key of the profile in the active will not be replaced
• The spring.profiles.include property can be used to unconditionally add active profiles, this sentence unconditionallyis more difficult to understand, let's go to the comment area, what does it mean?