Spring Boot Dry series: (ii) configuration file parsing

Objective

The previous article introduced spring boot, knowing that spring boot uses "habit better than Configuration" (there are a lot of configurations in the project, and there is a built-in configuration that allows you to run your projects quickly without having to manually configure them). So, if we want to play the spring boot, we need to know how to turn on the default configuration of each function module, which requires understanding the Spring boot configuration file application.properties.

Body

Spring Boot uses a global configuration file, Application.properties, under the Src/main/resources directory or/config the classpath. The role of the Sping boot global profile is to modify configuration values for some of the default configurations.

Next, let's work together to unravel the veil of the configuration file.

Note: If your project does not have this application.properties, then create a new one in the Src/main/java/resources directory.

Custom Properties

Application.properties provides support for custom attributes so that we can configure some constants here:

You can then bind to the property you want directly by using the annotation @value (value= "${config.name}") where you want to use it.

We start the project input http://localhost:8080 can see the print "Toot MD wish you all the rooster."

Sometimes there are too many properties, binding to the property field is too tired, the official advocate binding an object of the bean, here we build a Configbean.java class, the top needs to use the annotation @configurationproperties (prefix = " Com.dudu ") to indicate which

This is done by adding @enableconfigurationproperties to the Spring boot entry class and indicating which bean to load, and if you do not write Configbean.class, add it to the Bean class.

Finally, the controller can be introduced into the Configbean using the following:

Reference between parameters

You can also use a direct reference between the various parameters in Application.properties, as in the following settings:

So we can just use the Yearhope property.

Using a custom configuration file

Sometimes we do not want to put all the configuration in the application.properties, this time we can define a different, here I named Test.properties, the path is also placed under the src/main/resources.

Let's create a new Bean class, as follows:

Note here that there is a problem, if you are using a previous version of 1.5, you can specify the location of the properties file by locations, so:

However, after the 1.5 version does not have this attribute, found a half day to find adding @configuration and @propertysource ("Classpath:test.properties") can be read.

Random Value Configuration

${random} In the configuration file can be used to generate random values of various types, simplifying code generation, such as generating int, long, or string strings.

External configuration-command-line parameter configuration

Spring Boot is run based on the jar package, which can be run directly from the following command:

You can modify the Tomcat port number by following these commands:

As you can see, the consecutive two minus sign in the command line--is the identity that assigns the value of the attribute in Application.properties '.

So Java-jar Xx.jar--server.port=9090 is equivalent to adding an attribute server.port=9090 in Application.properties.

If you are afraid the command line is risky, you can use Springapplication.setaddcommandlineproperties (false) to disable it.

In fact, the spring boot application has several setup paths, and spring boot can get properties from multiple attribute sources, including the following:

1. The development tools under the root directory global Settings properties (' ~/.spring-boot-devtools.properties ' when the development tool is activated).

2. @testpropertysource annotations in the test.

3. @springboottest#properties annotation features in the test.

4. Command-line arguments

The attributes in the 5.spring_application_json (inline JSON embedding in environment variables or system properties).

6.ServletConfig initialization parameters.

7.ServletContext initialization parameters.

Jndi Properties in the 8.java:comp/env

9.JVM System Properties

10. Operating System Environment variables

11. Randomly generated attributes with random.* prefixes (you can apply them when setting other properties, such as ${random.long})

12. Application.properties or appliaction.yml files other than the application

13. Application.properties or APPLIACTION.YML files packaged within the application

14. Attribute source with @propertysource annotation

15. Default properties (specified by ' springapplication.setdefaultproperties ').

The list is sorted by group precedence, that is, any property set in the high-priority property source overrides the same property with the lower priority, and the command-line properties we mentioned above override the Application.properties property.

Priority of the configuration file

Application.properties and Application.yml files can be placed in four locations:

-External, in the/congfig subdirectory relative to the application running directory.

-External, in the directory where the application is running

-built-in, within config package

-Built-in, classpath root directory

Again, this list is sorted by priority, that is, Src/main/resources/config under Application.properties overrides src/main/ Resources under the same properties in Application.properties,

In addition, if you have both Application.properties and application.yml at the same priority location, the attributes inside the APPLICATION.YML will overwrite the attributes in the application.properties.

profile-Multi-environment configuration

When an application needs to be deployed to a different operating environment, some configuration details are usually different, the simplest of which is logging, which sets the log level to warn or higher, and writes the log to the log file, while development requires a log level of debug and the log output to the console.

If you follow the previous approach, which is to replace the configuration file every time you publish it, it's too much trouble, and the Spring boot profile gives us a solution that commands the parameters.

Here let's simulate, just simply modify the port to test.

The multi-Environment profile file name in spring boot needs to meet the ' application-{profile}.properties ' format, where ' {profile} ' corresponds to your environment ID, such as:

-Application-dev.properties: Development environment

-Application-prod.properties: Production environment

To use the corresponding environment, just use the Spring.profiles.active property in Application.properties to set the value corresponding to the {profile} mentioned above, which refers to the 2 dev, prod.

Of course you can also use the command line to start with parameters:

I add different port attribute server.port to different environments, and then switch to use according to the different spring.profiles.active specified. You can try it yourself. There is no code to be posted here.

In addition to using profile configuration files to configure our environment variables, in the code, we can also directly use @profile annotations to configure, such as database configuration, here we first define an interface:

Define two implementation classes separately to implement it

Which implementation class is specifically used by activating the configuration file

And then you can use it.

In addition to spring.profiles.active to activate one or more profiles, you can use Spring.profiles.include to overlay the profile

Summarize

This time on the spring boot application.properties configuration file to do a summary of the hope to help you, and finally paste the spring boot Common configuration properties, when needed to open the search.

(￣︶￣) [Spring Boot Dry series: Common Properties Summary] (http://tengj.top/2017/02/28/springbootconfig/)

Spring Boot Dry series: (ii) configuration file parsing