Detailed explanation of spring boot external configuration (configuration centralization)

preface

In order to configure flexibly in projects, we often use configuration files. Common configuration files, such as XML and properties, allow springboot to use properties and yaml files as external configuration. At present, the compiler's support for yaml language is not good enough. At present, it still uses the properties file as the external configuration.

Before spring cloud config came out, I implemented the ZK based configuration center and eliminated the local properties configuration file. The principle is very simple, but overloaded the mergeproperties() of propertyplaceholderconfigurer:

This implementation is quite easy to use in spring projects, but it has been found in some spring boot projects recently that the implementation of placeholder does not work well with the @ configurationproperties (prefix = "XXX") of spring boot,

That is, the properties are not resolved and can be read by @ value, but @ value configuration is cumbersome if there are many properties. It still tends to use the prefix of @ configurationproperties. Therefore, I looked at the spring boot document and found the propertysource

order:

* Devtools global settings properties on your home directory (~/.spring-boot-devtools.properties when devtools is active).

* @TestPropertySource annotations on your tests.

* @SpringBootTest#properties annotation attribute on your tests.

* Command line arguments.

* Properties from SPRING_ APPLICATION_ JSON (inline JSON embedded in an environment variable or system property)

* ServletConfig init parameters.

* ServletContext init parameters.

* JNDI attributes from java:comp/env.

* Java System properties (System.getProperties()).

* OS environment variables.

* A RandomValuePropertySource that only has properties in random.*.

* Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)

* Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)

* Application properties outside of your packaged jar (application.properties and YAML variants).

* Application properties packaged inside your jar (application.properties and YAML variants).

* @PropertySource annotations on your @Configuration classes.

* Default properties (specified using SpringApplication.setDefaultProperties).

It is not difficult to find that it will check the properties in Java System props, that is, just write the properties read by mergerproperties into Java System props, look at the source code and find a breakthrough point

In order to avoid excessive impact, a switch is set to determine whether to write system properties. If it is a spring boot project, it will be turned on, so as to minimize the impact on online non spring boot projects, and then the @ configurationproperties of spring boot can read the properties perfectly;

See: org.org for specific code springframework. boot. context. properties. ConfigurationPropertiesBindingPostProcessor

summary

The above is the whole content of this article. I hope the content of this article has a certain reference value for your study or work. If you have any questions, you can leave a message. Thank you for your support for programming tips.