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 POMs
0
.
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 environmentapplication-dev.properties
,
application-test.properties
,
application-prod.properties
In these 3 files all set different
application.properties
1
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.