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.properties
application-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.properties
The common content is configured in and set to the spring.profiles.active=dev
development environment as the default configuration
application-{profile}.properties
Configure different contexts in each environment
- Activating configuration of different environments by command-line mode
Spring Cloud Spring Boot mybatis Distributed microservices Cloud Architecture (iv) attribute profiles detailed (2)