Read the table of contents:
1. Custom properties and loading
2. Test class
3. References between parameters
4. Set property values via command line
5. Multi-environment configuration
I believe that many people choose Spring Boot mainly because it can not only take into account the powerful functions of Spring, but also realize the convenience of rapid development. In the process of using Spring Boot, the most intuitive feeling is that there is no more XML configuration content when integrating Spring applications by ourselves. Instead pom.xml, we introduce modularization in Spring Boot Starter POMs, in which each module has its own default configuration, so if It is not a special application scenario, you only need application.propertiesto complete some attribute configuration in the application to open the application of each module.
In the previous articles, we have mentioned about application.propertiesthe use, mainly used to configure database connections, log related configuration, etc. In addition to these configuration contents, this article will specifically introduce some application.propertiesother features and usage methods in the configuration.
1. Custom properties and loading
When we use Spring Boot, we usually need to define some properties that we use ourselves. We can define them directly as follows:
com.blog.name=example com.blog.title=Spring Boot2.0
Then @Value("${属性名}")load the corresponding configuration properties through annotations, as follows:
@Component
@Getter
@Setter
public class BlogProperties {
@Value("${com.blog.name}")
private String name;
@Value("${com.blog.title}")
private String title;
}
By convention, unit tests are used to verify that the properties in BlogProperties have been loaded according to the configuration file.
2. Test class
Spring Boot 1.3.X version test class
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(Application.class)
public class CommonTest {
@Autowired
private BlogProperties blogProperties;
@Test
public void getHello() throws Exception {
Assert.assertEquals(blogProperties.getName(), "example");
Assert.assertEquals(blogProperties.getTitle(), "Spring Boot2.0");
}
}
Dividing line =========================================
Spring Boot1.5.X and Spring Boot2.0 and above test classes
@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest(classes = Application.class)
public class CommonTest {
...
}
3. References between parameters
application.propertiesIt can also be used by direct reference between the various parameters in , just like the following settings :
com.blog.name=example
com.blog.title=Spring Boot2.0
com.blog.desc=${com.blog.name} is trying ${com.blog.title}
com.blog.descnameThe parameter refers to the sum property defined above, and titlethe final value of that property is example正在尝试Spring Boot2.0.
4. Set property values via command line
I believe that users who have used Spring Boot for a period of time must know this command: java -jar xxx.jar --server.port=8888, Set the port of the xxx.jar application to 8888 by using the --server.port property.
When running on the command line, two consecutive minus signs --are application.propertiesthe identifiers for assigning the attribute value in . Therefore, the java -jar xxx.jar --server.port=8888command is equivalent to application.propertiesadding a property server.port=8888in the . This setting is visible in the sample project. The reader can verify by deleting the value or setting the value using the command line.
Modifying property values through the command line provides good convenience, but is it not very safe to change the parameters of the application running through the command line? Yes, so Spring Boot also intimately provides settings for shielding command line access properties, which can be shielded with only this setting: SpringApplication.setAddCommandLineProperties(false).
Multi-environment configuration
When we develop Spring Boot applications, usually the same set of programs will be applied and installed in several different environments, such as: development, testing, production, etc. The configuration of the database address, server port, etc. for each environment will be different. If the configuration file must be frequently modified when packaging for different environments, it will be a very tedious and error-prone thing.
For multi-environment configuration, the basic ideas of various project construction tools or frameworks are the same. By configuring multiple configuration files for different environments, and then specifying the content to be packaged through the packaging command, the packaging is differentiated, and Spring Boot is no exception. , or even simpler.
The format that the multi-environment configuration file name needs to meet in Spring Boot application-{profile}.properties, which {profile}corresponds to your environment identifier, such as:
application-dev.properties: Development environmentapplication-test.properties:test environmentapplication-prod.properties:Production Environment
As for which specific configuration file will be loaded, it needs to be set application.propertiesthrough spring.profiles.activeproperties in the file, and its value corresponds to the {profile}value.
For example: the content of the configuration file spring.profiles.active=testwill be loadedapplication-test.properties
Below, take the configuration of different service ports in different environments as an example to conduct sample experiments.
-
Create different configuration files for each environment
application-dev.properties,application-test.properties,application-prod.properties -
Different properties are set in these three files
server.port, such as: dev environment is set to 1111, test environment is set to 2222, prod environment is set to 3333 -
Set in application.properties,
spring.profiles.active=devwhich means that the default is set in the dev environment -
Test loading of different configurations
- Execute
java -jar xxx.jar, you can observe that the service port is set to1111, which is the default development environment (dev) - Execute
java -jar xxx.jar --spring.profiles.active=test, you can observe that the service port is set to2222, that is, the configuration of the test environment (test) - Execute
java -jar xxx.jar --spring.profiles.active=prod, you can observe that the service port is set to3333, that is, the configuration of the production environment (prod)
- Execute
According to the above experiments, the configuration ideas of multiple environments can be summarized as follows:
application.propertiesConfigure common content in and setspring.profiles.active=devthe development environment as the default configurationapplication-{profile}.propertiesConfigure different content for each environment in- Activate the configuration of different environments through the command line