An in depth understanding of the Spring Boot property profile

  • 2020-06-12 08:57:47
  • OfStack

preface

I believe many people choose Spring Boot mainly because of its ability to combine the powerful features of Spring with the convenience of rapid development. In the process of using Spring Boot, the most intuitive feeling is that there is no original integration of Spring XML application when the various XML configuration content, instead of it is in pom.xml In the introduction of modular Starter POMs , where each module has its own default configuration, so if it is not a special application scenario, it only needs to be in the application.properties The completion of 1 property configuration can open the application of each module.

It has been mentioned in previous articles application.properties The use of, mainly used to configure database connection, log related configuration. In addition to these configuration contents, this article will introduce some details in 1 application.properties Additional features and usage in the configuration.

Custom properties and loading

When we use Spring Boot, we usually need to define some properties for our own use. We can directly define them as follows:


com.didispace.blog.name= Program the ape DD
com.didispace.blog.title=Spring Boot The tutorial 

Then through @Value("${属性名}") Annotation to load the corresponding configuration properties as follows:


@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, unit tests verify that the properties in BlogProperties have been loaded according to the configuration file.


@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(Application.class)
public class ApplicationTests {
 @Autowired
 private BlogProperties blogProperties;
 @Test
 public void getHello() throws Exception {
 Assert.assertEquals(blogProperties.getName(), " Program the ape DD");
 Assert.assertEquals(blogProperties.getTitle(), "Spring Boot The tutorial ");
 }
}

References between parameters

in application.properties Can also be used by direct reference between the parameters, as shown in the following Settings:


com.didispace.blog.name= Program the ape DD
com.didispace.blog.title=Spring Boot The tutorial 
com.didispace.blog.desc=${com.didispace.blog.name} Working on the book ${com.didispace.blog.title} " 

com.didispace.blog.desc The parameter references the one defined above name and title Property, and the final value of that property is Starter POMs0 .

Using random Numbers

In some cases, there are parameters that we would like to have that are not fixed, such as keys, service ports, etc. Spring Boot properties profile can be accessed ${random} To generate the int value, long value, or string string to support random values for attributes.


#  Random string 
com.didispace.blog.value=${random.value}
#  random int
com.didispace.blog.number=${random.int}
#  random long
com.didispace.blog.bignumber=${random.long}
# 10 Random number within 
com.didispace.blog.test1=${random.int(10)}
# 10-20 The random number 
com.didispace.blog.test2=${random.int[10,20]}

Set property values from the command line

For those of you who have been using Spring Boot for a while, 1 must know this command: java -jar xxx.jar --server.port=8888 , by using �server.port Property to set the port of xxx. jar to 8888.

At the command line, two consecutive minus signs -- that's right application.properties The identifier for which attribute values are assigned. So, java -jar xxx.jar --server.port=8888 The command is the same thing as saying we're in application.properties Add attributes to server.port=8888 , the setting is visible in the sample project, and the reader can verify it by deleting the value or setting it using the command line.

Modifying property values from the command line is a nice convenience, but changing the parameters of an application from the command line is not safe. Yes, so Spring Boot also provides a nice way to block command line access properties. SpringApplication.setAddCommandLineProperties(false)  .

Multi-environment configuration

When we develop Spring Boot applications, the same set of programs will usually be applied and installed in several different environments, such as development, testing, production, etc. Each of these environments will have a different configuration of database addresses, server ports, and so on, and it will be tedious and error-prone to change the configuration files frequently when packaging for different environments.

For multi-environment configuration, the basic idea of various project building tools or frameworks is 1. By configuring multiple configuration files of different environments, and then specifying what needs to be packaged by packaging command, we can differentiate packaging. Spring Boot is no exception, or even simpler.

In Spring Boot multi-environment configuration file names need to be met application-{profile}.properties The format of which {profile} Correspond to your environment identifier, 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, need to be in application.properties File through spring.profiles.active Property, whose values correspond {profile} Value.

Such as: spring.profiles.active=test The application-ES105en.properties profile content is loaded

The following is a sample experiment with different service ports configured in different environments.

Create different profiles for each environment application-dev.properties , application-test.properties , application-prod.properties In these 3 files all set different application.properties1 Properties such as dev set to 1111, test set to 2222, prod set to 3333 application.properties Set in the spring.profiles.active=dev That is, dev is the default setting Test the loading of different configurations

perform java -jar xxx.jar , you can observe that the service port is set to 1111, the default development environment (dev)

perform java -jar xxx.jar --spring.profiles.active=test , you can observe that the service port is set to 2222, which is the configuration of the test environment (test)

perform java -jar xxx.jar --spring.profiles.active=prod , you can observe that the service port is set to 3333, which is the configuration of the production environment (prod)

According to the above experiment, the idea of multi-environment configuration can be summarized as follows:

application.properties , and set spring.profiles.active=dev With the development environment as the default configuration application-{profile}.properties Configure the different contents of each environment Activate the configuration of different environments from the command line

Example code: chapter2-1

conclusion

The above is the whole content of this article, I hope the content of this article can bring 1 definite help to your study or work, if you have any questions, you can leave a message to communicate.


Related articles: