Spring-boot actual Combat "08" "Go": Spring Boot Property configuration file detailed

It is believed that many people choose spring boot primarily because it takes into account the power of spring and the ease with which it can be developed quickly. In the spring boot use process, the most intuitive feeling is not the original integration of the spring application of a large variety of XML configuration content, instead of it is introduced in the pom.xml modular Starter POMs , each module has its own default configuration, so if not a special application scenario, It is only necessary to complete some of the properties in the application.properties configuration to open the application of each module.

In previous articles, there was a reference to application.properties the use, mainly used to configure database connections, log-related configuration and so on. In addition to these configuration content, this article describes some application.properties additional features and how to use them in the configuration.

Custom properties and loading

When we use spring boot, we often need to define some of our own properties, which we can define directly as follows:

12	Com.didispace.blog.name= Program Ape ddcom.didispace.blog.title=spring Boot Tutorial

@Value("${属性名}")the corresponding configuration properties are then loaded with annotations, as follows:

1234567891011

@Component public class blogproperties { @Value ("${com.didispace.blog.name}") private String name; @Value ("${com.didispace.blog.title}")  private String title; //Omit getter and setter }

By convention, the unit tests are passed to verify that the properties in the Blogproperties have been loaded according to the configuration file.

123456789101112131415

@RunWith (Springjunit4classrunner.class) @SpringApplicationConfiguration (Application.class) public class applicationtests { @AutowiredPrivate blogproperties  blogproperties; @Test public void Gethello() throws Exception {assert.assertequals (Blogproperties.getname (), "program ape DD"); Assert.assertequals (Blogproperties.gettitle (), "Spring boot Tutorial"); }

References between parameters

application.propertiesYou can also use a direct reference between the various parameters in, as in the following settings:

123	Com.didispace.blog.name= Program Ape ddcom.didispace.blog.title=spring boot tutorial com.didispace.blog.desc=${ Com.didispace.blog.name} is working hard to write "${com.didispace.blog.title}"

com.didispace.blog.descThe parameter references the name and attributes defined above title , and finally the value of the property is 程序猿DD正在努力写《Spring Boot教程》 .

Using random numbers

In some cases, some parameters we need to hope that it is not a fixed value, such as keys, service ports, etc. Spring Boot's property configuration file can be used ${random} to produce an int value, a long value, or a string string to support a random value of a property.

12345678910

# random string com.didispace.blog.value=${random.value}# random intcom.didispace.blog.number=$ {Random.int} # Random Longcom.didispace.blog.bignumber=${random.long}# 10 or less random number Com.didispace.blog.test1 =${random.int (Ten)}# 10-20 random number com.didispace.blog.test2=${random.int[10,20]}

Setting property values from the command line

Believe that users who have used spring boot for a period of time must know this command: java -jar xxx.jar --server.port=8888 by using the –server.port property to set the port of the Xxx.jar app to 8888.

When run at the command line, the consecutive two minus -- signs are the application.properties identifiers that assign values to the property values in. So, the command, which is equivalent to the addition of a property in, is visible in the java -jar xxx.jar --server.port=8888 application.properties server.port=8888 sample project and can be verified by either deleting the value or setting the value using the command line.

Modifying property values from the command line is a good convenience, but is it not safe to change the parameters of the application run from the command line? Yes, so spring boot also provides a nice way to mask the command line access properties, which only needs to be set to block: SpringApplication.setAddCommandLineProperties(false) .

Multi-environment configuration

When we develop spring boot applications, the same set of programs is usually applied and installed into several different environments, such as: development, testing, production, etc. Each environment's database address, server port and so on configuration will be different, if you are packaging for different environments to frequently modify the configuration file, it will be a very cumbersome and prone to error.

For a multi-environment configuration, the basic idea of a variety of project building tools or frameworks is consistent, and the Spring boot is no exception, or simpler, by configuring multiple profiles of different environments and then packaging them to specify what needs to be packaged.

In spring boot, the multi-environment profile file name needs to be in application-{profile}.properties a format that {profile} corresponds to your environment identity, such as:

• application-dev.properties: Development environment
• application-test.properties: Test environment
• application-prod.properties: Production environment

As to which specific configuration file will be loaded, it needs to be set in the application.properties file by spring.profiles.active property, and its value corresponds to the {profile} value.

such as: The spring.profiles.active=test application-test.properties configuration file contents will be loaded

Below, a sample experiment is performed with different service ports configured in different environments.

• Create a different profile for each environment, application-dev.properties application-test.propertiesapplication-prod.properties

• All three files are set with different server.port properties, such as: Dev environment set to 1111,test environment set to 2222,prod environment set to 3333

• Application.properties spring.profiles.active=dev , which means that the dev environment is set by default

• Test loading of different configurations

  • Execution java -jar xxx.jar , you can observe that the service port is set to the 1111 default development environment (DEV)
  • Execution java -jar xxx.jar --spring.profiles.active=test , you can observe that the service port is set to 2222 , that is, the configuration of the test environment (test)
  • Execution java -jar xxx.jar --spring.profiles.active=prod , you can observe that the service port is set to 3333 , that is, the configuration of the production environment (PROD)

According to the above experiment, we can summarize the multi-environment configuration ideas as follows:

• application.propertiesThe common content is configured in and set to the spring.profiles.active=dev development environment as the default configuration
• application-{profile}.propertiesConfigure different contexts in each environment
• Activating configuration of different environments by command-line mode

Complete Example Chapter2-1-1

Spring-boot actual Combat "08" "Go": Spring Boot Property configuration file detailed