Shulou(Shulou.com)06/01 Report--

Editor to share with you Spring Boot 2.4 configuration file will load the mechanism of what changes, I believe that most people do not understand, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

Spring Boot 2.4.0.M2 has just been released, and it refactores the way application.properties and application.yml files are loaded. If your application uses only a single application.properties or application.yml as the configuration file, you may not feel any difference. But if your application uses a more complex configuration (for example, Spring Cloud configuration Center, etc.), you need to understand the content of the change and why.

Why make these changes?

With the release of the latest version of Spring Boot, Spring has been working to improve native support for Kubernetes. In Spring Boot 2. 3, Kubernetes Volume configuration support was officially added, but failed to implement.

Volume configuration mount is a common feature of Kubernetes, where the ConfigMap directive is used to display the configuration directly on the file system. You can load a complete YAML file that contains multiple key and value merges, or you can use a simpler directory tree format where the file name is the key and the file content is the value.

Hope to provide both support and be compatible with our existing application.properties and application.yml. For this, you need to modify the ConfigFileApplicationListener class.

ConfigFileApplicationListener problem

The configuration file loading class ConfigFileApplicationListener in Spring Boot belongs to the core underlying code, and it is very difficult to maintain each time. It is not because of coding errors or the lack of related unit tests, but it is difficult to solve previous problems when adding new features.

That is:

Profiles are so flexible that you can enable other profiles in the current file.

The loading order of the document is not fixed.

Take the following example:

Security.user.password: usera---spring.profiles: localsecurity.user.password: userbrunlocal: true---spring.profiles:! devspring.profiles.include: localsecurity.user.password: userc

Here, we have a multi-document YAML file (a file consists of three logical documents separated by--).

If you use-- spring.profile.actives=prod to run, what is the value of security.user.password? Do you want to set runlocal property? Is the middle part of the document included because the configuration file was not activated during processing?

We often encounter problems with the processing logic of this file, but when we try to fix them, we end up with all kinds of negative problems.

As a result, two major changes are made to the way Properties and YAML files are loaded in Spring boot 2.4:

The documents are loaded in the defined order.

The profiles activation switch cannot be configured in a specific environment.

Document sorting

Starting with Spring Boot 2.4, loading Properties and YAML files will follow, and declaring that the first-ordered attributes in the document will be overridden by the last attributes.

This is the same as the collation of .properties. We can think about it. Every time we put a Value into a Map and a new value with the same key is put in, the existing Value will be replaced.

Similarly, for Multi-document 's YAML files, the lower sort will be overwritten by the higher one:

Test: "value"-test: "overridden-value" Properties file supports multiple document attributes

In Spring Boot 2.4, Properties supports a multi-document feature similar to YAML. The multi-document properties file uses comments (#) followed by three (- -) dashes to separate documents (choose to use comments to make the existing IDE support properly).

For example, the equivalent properties of the above YAML is:

Test=value#---test=overridden-value specific environment activation configuration

The above example actually doesn't make any sense, and it is more common in our development process to declare that a property is activated only in a specific environment.

Spring.profiles can be configured in Spring Boot 2.3to achieve this. However, in Spring Boot 2.4, the property was changed to spring.config.activate.on-profile.

For example, if we want the test property to override dev Profile only when it is activated, we can use the following configuration:

Test=value#---spring.config.activate.on-profile=devtest=overridden-valueProfile Activation

Use the spring.profiles.active attribute in the root configuration file of the application.properties or application.yaml file to stimulate the relevant environment file.

For example, it looks like this:

Test=valuespring.profiles.active=local#---spring.config.activate.on-profile=devtest=overridden value

What is not allowed is to use the spring.profiles.active property with spring.config.activate.on-profile. For example, the following file throws an exception:

Test=value#---spring.config.activate.on-profile=devspring.profiles.active=local # will failtest=overridden value

This new restriction makes application.properties and application.yml files easier to understand. Make Spring Boot itself easier to manage and maintain.

Profile Groups

Profile Groups is a new feature in Spring Boot 2.4 that allows you to extend a single profile to multiple subprofiles. For example, suppose you have a complex set of @ Configuration classes that can be conditionally enabled using the @ Profile annotation. Use @ Profile ("proddb") to open database configuration, @ Profile ("prodmq") to turn on message configuration, and so on.

Using multiple configuration files makes our code easier to understand, but it's not an ideal choice for deployment. If the user needs to activate proddb, prodmq, prodmetrics, etc. Then Profile Groups allows you to do this.

You can define spring.profiles.group in an application.properties or application.yml file, so turning on prod is equivalent to activating the entire environment of this group. For example:

Spring.profiles.group.prod=proddb,prodmq,prodmetricsImporting extension Configuration

Now that we have solved the basic problem of profile processing, we are finally able to consider the new features we want to provide. The main feature we provide using Spring Boot 2.4 is to support the import of other configurations.

For earlier versions of Spring Boot, it was difficult to import properties or yaml files other than application.properties and application.yml. You can use the spring.config.additional-location attribute, but it can handle a very limited number of file types.

The new spring.config.import attribute can be used directly in application.properties or application.yml files in Spring Boot 2.4. For example, you want to import a "ignored git" developer.properties file so that any developer on the team can change the properties quickly:

Application.name=myappspring.config.import=developer.properties

You can even use spring.config.import in combination with spring.config.activate.on-profile. For example, here prod.properties is loaded only when the prod configuration file is active:

Spring.config.activate.on-profile=prodspring.config.import=prod.properties

Import can be thought of as other documents inserted under the document that declares them. They follow the same top-down order as regular multi-document files: imports are imported only once, no matter how many times they are declared.

Volume mount configuration

The import definition uses the same syntax as URL as its value. If your location does not have a prefix, it is considered a regular file or folder. However, if you use the configtree: prefix, tell Spring Boot that you will expect to use the configuration tree mounted by Kubernetes volume at that location.

For example, you can configure in application.properties:

Spring.config.import=configtree:/etc/config

If you have the following loads:

Etc/ +-config/ +-my/ | +-application +-test

You will have the my.application and test properties in Spring Environment. The value of my.application is the content of / etc/config/my/application, and the value of test is the content of / etc/config/test.

Activate based on cloud platform type

If you only want the configuration mounted by Volume (or any attribute of that content) to be active on a specific cloud platform, you can use the spring.config.activate.on-cloud-platform attribute. It works like spring.config.activate.on-profile, except that it uses the value of CloudPlatform instead of the profile name.

If we want to enable the above configuration tree when deploying to Kubernetes, we can do the following:

Spring.config.activate.on-cloud-platform=kubernetesspring.config.import=configtree:/etc/config supports other locations

The location string specified in the spring.config.import attribute is fully pluggable and can be extended by writing several custom classes, and third-party libraries will support custom locations. For example, you can think of third-party jar files, such as archaius://... , vault://... Or zookeeper://... .

If you are interested in adding additional location support, check out the javadoc of the org.springframework.boot.context.config package ConfigDataLocationResolver and ConfigDataLoader.

Version rollback

As described above, Spring Boot's functional changes to the configuration file are very significant. Considering the compatibility of the lower version

You can set the spring.config.use-legacy-processing=true property to revert to the previous version of the file processing mechanism.

These are all the contents of this article entitled "what are the changes in the loading mechanism of Spring Boot 2.4 configuration files?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.