SpringBoot multi-environment configuration, the old is outdated, the new people do not know

If you are using Spring Boot 2.4 or later, you will notice that Spring.profiles.active, the multi-environment support configuration item in Spring Boot, has been deprecated. And Spring Boot has been gradually pushing new configuration, perhaps many people do not know, this article will take you to see what it is.

Spring Boot multi-environment configuration

Before we look at the new configuration approach, let’s review the common multi-environment configuration approach. It is common in projects that a project is deployed to multiple environments, such as development, test, and production. Different environments have different configuration files. Therefore, Spring Boot provides a way based on the spring.profiles. Active configuration item to easily specify the configuration file for the corresponding environment.

According to Spring Boot conventions, a primary configuration file application.yml(or.properties) is defined, followed by configuration files for other environments in the application-{profile}.properties format. {profile} indicates the environment identifier. For example, application-dev.yml indicates the development environment, application-test-yml indicates the test environment, and application-prod.yml indicates the production environment.

Spring.profiles. Active can be configured in application.yml to specify which environment is currently used:

server:
  port: 8080

spring:
  profiles:
    active: dev
Copy the code

When starting a SpringBoot project, you can also specify one or more configuration files with parameters:

-Dspring.profiles.active=dev,master
Copy the code

In this way, a jar package can be used in different environments by changing the parameters, and it does not need to be packaged frequently. The above way is the most common one we have.

Single File Configuration

server:
  port: 8080

spring:
  profiles:
    active: test
---
spring:
  profiles: test

server:
  port: 9090
---
spring:
  profiles: prod

server:
  port: 9090
Copy the code

The following profiles are active: test
Copy the code

New forms of use

Regardless of which form you use, the spring.profiles. Active configuration item is underlined, i.e. deprecated, when using Spring Boot 2.4 or later. Of course, although deprecated, it can still be used normally if you want to use it, but as an aspiring programmer, it still feels uncomfortable to have that delete line. Since knowledge ready, then take a look at the Spring Boot support the latest Spring configuration way. Config. Activate. On – profile.

Spring Boot for a wide range of changes, the main motivation has two, one is compatible with the support of Kubernetes is a repair caused by ConfigFileApplicationListener class file processing problem. As a result, there are two major changes in how files are loaded: documents will be loaded in the order defined, and the Profiles activation switch cannot be configured in a particular environment.

Based on spring. Config. Activate the on – the profile to modify the configuration above, using the sample is as follows:

server:
  port: 8080

spring:
  profiles:
    active: test
---
spring:
  config:
    activate:
      on-profile: dev

server:
  port: 9090
---
spring:
  config:
    activate:
      on-profile: prod

server:
  port: 9090
Copy the code

That is to say, in a specific environment (test and prod, etc.) will spring configuration. The profiles or spring. Profiles. The active configuration to replace to spring. Config. Activate. On – profile. The use of the active configuration spring.profiles. Active has not changed. When the application is started, the configuration method for loading different environments remains unchanged, and the spring.profiles. Active parameter is still used.

If you want to set the default configuration environment, it is still specified in the public section via spring.profiles.active.

Other Matters needing attention

YAML configuration sequencing changes

In Spring Boot 2.4, configuration parameters are loaded in the order defined in the configuration file, and the parameters loaded after activation override the previous ones. If some configuration parameters overwrite each other, make sure that the required parameters are placed at the end of the file.

Profile configuration overrides the change

A return to traditional patterns

If the current project’s configuration file is not currently suitable or convenient for upgrading to the new mode, you can specify the previous processing logic through configuration. Set the parameters as follows:

spring.config.use-legacy-processing = true
Copy the code

However, this approach is not recommended for long-term use, after all, the development trend of technology has been set, in the future, the old model may be abandoned.

summary