In the SpringBoot project, it can be said that getting configuration properties is a very simple matter. After writing the configuration in the aplication.yml file, we can directly bind and obtain it through the @Value annotation. In addition, we can use @ configurationproperties to bind the structured configuration to POJO, and then use it in the project. So when using it, I wonder if you have thought about it?

If the above is clear, then this article will not be particularly helpful; If you have any questions about this, just answer them one by one.

This project is developed with the help of Spring Boot 2.2. 1 Release +Maven 3. 5. 3+ ideas.

The following is the core pom.xml (the source code can be obtained at the end of the article)

Suppose we have customized a function module now, which contains some parameters that we have defined and supports injection through yaml configuration file.

First, we can define a configuration class BindConfig.

Please note that prefix = hhui.bind in the above comments only means that the properties with the prefix hhui.bind in the configuration file will be read and assigned to this class in turn.

The corresponding configuration files are as follows

Matters needing attention

On the last point above, this means that we can declare an internal class to bind the configuration information in the automatic configuration class, as shown below.

After we decorate the configuration class through @ConfigurationProperties, will it take effect directly? Generally speaking, there are three ways to make it work.

Add comments such as @Component and @Configuration directly on the configuration class, and let the Spring container scan and load.

When using this method, you need to pay attention to automatically scanning the configuration classes in the package path, otherwise it may not be scanned (mainly when providing services as a third-party jar package).

It is also an optional scheme to regard it as an ordinary bean and realize it through bean registration. The general implementation method is as follows.

On the configuration class, after adding this comment, configuration registration can be realized, such as commonly used gestures.

Among the above three registration methods, the first two ideas are to use configuration classes as beans, and the third idea is consistent with the active registration of beans (so if you want to realize the active registration of beans, you can consider its implementation logic).

What if, in our configuration, we originally expected to receive a parameter of type int, but it was actually filled as a non-integer?

For example, in the previous configuration class, our actual configuration file will be filled with age 18y to see what will happen in the end.

Simple demonstration, directly in the startup class test.

After the parameter is abnormal, direct startup fails. Failure is allowed if the requirements for parameters are not so strict. We can set ignoreInvalidFields = true.

After executing again, you will find that the startup is normal, and the output is as follows

Pay attention to the age above, because the illegal parameter passed in is null.

explain

Used in conjunction with the default value of+ignorininvalidfields to support the maximum availability of the configuration:

Perform the output again, for example

Besides basic types, can common configurations nest custom objects, and how to resolve non-basic types?

We define a new Pwd class.

Then expand BindConfig.

At this point, the yaml configuration file corresponding to mainPwd can be set as follows.

As can be seen from the above introduction, custom POJO classes are supported, and there is no difference in using gestures.

In addition, the use of lists and maps is illustrated with examples.

The Pwd class we defined above mainly uses the setter method to plug in the matching attributes. If my configuration is a json string, can I inject it into the POJO class?

The corresponding Jwt class is as follows

At this point, if you want to achieve the above configuration resolution, you can support it by implementing the interface of org. Springframe. core.convert.converter, and through the comment @ configurationPropertiesBinding, it is indicated that this is a configuration attribute conversion class. Without this comment, it will not take effect.

explain

When using custom configuration resolution rules, please pay attention to two points.

Spring provides some default configuration parsing rules, such as

What happens to the configuration class without this attribute in the corresponding class?

For example, for the previous BindConfig, there was no notExist attribute, but it was added in the configuration file.

It was found that there was no effect after actual measurement. By looking at the members of @ConfigurationProperties annotation, it is found that ignoreUnknownFields=false can be set, which literally means that there are unrecognized members, which will not be slightly wrong, but it will not take effect in the actual test.

Parameter verification is a common case. For example, the configuration before age, this parameter is basically not allowed to be negative. If it is necessary to validate the parameters, we can use @Validated to validate them.

Add pom correlation

Then add @Validated on the configuration class, and then you can add corresponding restrictions on the fields that need to be validated.

If the age parameter we set does not meet the above conditions

Retesting will find the following reported errors.

Usually, in the process of Spring development, when adding configuration to yaml file, there will be a very friendly prompt with idea, which can complete parameter configuration very friendly.

So what should our custom parameters do to achieve this effect?

Add a dependency at the beginning of the article

After adding the above dependencies, package the mvn clean package, and then you will find a spring-configuration-metadata. JSON under META-INF.

Then it will be done automatically.

explain

Idea recommends adding the plug-in Spring Assistant, which supports very friendly configuration injection.

This paper introduces that @ConfigurationProperties modifies POJO class to realize configuration binding, which can be registered by declaring this class as a normal bean or using @EnableConfigurationProperties.

When configuring parameters, it should be noted that if the parameter types are inconsistent, the project will not start. You can avoid this by setting the configuration property # ignoreininvalidfields = true.

By implementing the interface converter+@ ConfigurationPropertiesBinding, we can define the transformation rules of parameter analysis and realize the parameter analysis of various postures.

Automatic prompt support configuration is also relatively simple. Add the dependency of org.springframework.boot: spring-boot-configuration-processor. After packaging, there will be a json file spring-configuration-metadata.json in META-INF.

Project source code

Series of blog posts

You might as well trust all the books. The above contents are purely statements. Due to limited personal ability, it is inevitable that there will be omissions and mistakes. If you find bugs or have better suggestions, please criticize and correct me. I appreciate it.

The following is a dusty personal blog, which records all the blog posts in study and work. Welcome to visit.