Solve the problem that the specified parameters are invalid when starting after spring boot is typed into jar packet

Invalid parameter specified when spring-boot is typed as jar startup

Today, the background project was modified to use spring. profiles to specify the configuration file to use at startup.

Use java-jar after you have added the configuration file to your project.\ base-exec. jar-spring. profiles. active=dev-server. port=9121.

Check the rules of configuration file writing, and say 1 rule here

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 and so on. The configuration of database address, server port and so on will be different in each environment. If you have to modify the configuration file frequently when packaging for different environments, it will be a very tedious and error-prone thing.

For multi-environment configuration, the basic idea of various project construction tools or frameworks is 1. By configuring multiple configuration files of different environments, and then specifying the contents to be packaged through packaging commands, Spring Boot is no exception, or simpler.

In Spring Boot, the multi-environment profile name needs to meet the format of application-{profile}. properties, where {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 through the spring. profiles. active property, whose value corresponds to the {profile} value.

For example: spring. profiles. active=test will load the application-test. properties configuration file contents

Next, take different service ports configured in different environments as an example to carry out sample experiments.

Create different configuration files for each environment application-dev. properties, application-test. properties, application-prod. properties

Set different server. port attributes in these three files, such as: dev environment is set to 8080, test environment is set to 9090, prod environment is set to 80

spring. profiles. active=dev is set in application. properties, that is to say, dev environment is set by default

Test the loading of different configurations:

Execute java-jar xxx. jar and observe that the service port is set to 8080, which is the default development environment (dev)

Execute java-jar xxx. jar-spring. profiles. active = test and observe that the service port is set to 9090, which is the configuration of the test environment (test)

Execute java-jar xxx. jar-spring. profiles. active = prod and observe that the service port is set to 80, which is the configuration of the production environment (prod)

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

application. properties, and set spring. profiles. active=dev with the development environment as the default configuration

application-{profile}. Configurations in properties vary from environment to environment

Check the setAddCommandLineProperties configuration

Managing configuration in an application is not an easy task, especially when the application needs to be deployed in multiple environments. Usually, it is necessary to provide a corresponding property file for each environment, which is used to configure the respective database connection information, server information and third-party service account, etc. Usually, application deployment includes several environments such as development, test and production. There is an overlay relationship between configurations of different environments. The configuration in the test environment overrides the development environment, while the configuration in the production environment overrides the test environment. The Spring framework itself provides a variety of ways to manage configuration properties files. You can use PropertyPlaceholderConfigurer before Spring 3.1.

Spring 3.1 introduces a new environment (Environment) and profile information (Profile) API, which is a more flexible way to handle different environments and configuration files. However, the problem with Spring is that there are too many choices for developers to know what to do. Spring Boot provides a unified way to manage application configuration, allowing developers to use properties files, YAML files, environment variables and command line parameters to define configuration values with different priorities.

Spring Boot provides a complex order of configuration priorities. According to the order of priority from high to low, the specific list is as follows.

Command line arguments.

Java system parameters obtained through System. getProperties ().

Operating system environment variables.

The JNDI attribute obtained from java: comp/env.

The "random. *" attribute generated by RandomValuePropertySource.

Apply properties files other than Jar files. (Through the spring. config. location parameter)

Apply the properties file inside the Jar file.

Properties file declared through the "@ PropertySource" annotation in the application configuration Java class (Java class containing the "@ Configuration" annotation).

Default properties declared through "SpringApplication. setDefaultProperties".

This configuration priority of Spring Boot seems complicated, but it is actually very reasonable. For example, the priority of command line parameters is set to the highest.

This has the advantage of quickly modifying configuration parameter values in a test or production environment without repackaging and deploying the application.

By default, the SpringApplication class converts command-line arguments beginning with "--" into configuration parameters that can be used in applications. For example, "--name=Alex" sets the value of configuration parameter "name" to "Alex". If you do not need this functionality, you can disable parsing command-line arguments through "SpringApplication. setAddCommandLineProperties (false)".

Check the setAddCommandLineProperties configuration

public static void main(String[] args) {
    SpringApplication springApplication = new SpringApplication(WebApplication.class);
    springApplication.run(args);
}

Check whether the args parameter is passed in. This is the problem with my project

public static void main(String[] args) {
     new SpringApplication.run(WebApplication.class);
}

The spring-boot project cannot pass in parameters from the command line after being packaged

java -jar .\tk-provider.jar --spring.profiles.active=test

I wanted to run the project with the configuration file of the test environment, but when the project started, 1 was run with the dev configuration file.

java -jar .\tk-provider.jar --spring.profiles.active=test
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/D:/softwareWorkspace/hqtx/HqService/ServiceProvider/tk-provider/target/tk-provider.jar!/BOOT-INF/lib/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/D:/softwareWorkspace/hqtx/HqService/ServiceProvider/tk-provider/target/tk-provider.jar!/BOOT-INF/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
====================> : Spring Boot  Initialize environment variables 

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.0.4.RELEASE)

2018-08-23 16:14:48.494  INFO 349004 --- [           main] com.hq.tk.TkApplication                  : Starting TkApplication v1.0-SNAPSHOT on longqin with PID 349004 (D:\softwareWorkspace\hqtx\HqService\ServiceProvider\tk-provider\target\tk-provider.jar started by Administrator in D:\softwareWorkspace\hqtx\HqService\ServiceProvider\tk-provider\target)
2018-08-23 16:14:48.497 DEBUG 349004 --- [           main] com.hq.tk.TkApplication                  : Running with Spring Boot v2.0.4.RELEASE, Spring v5.0.8.RELEASE
2018-08-23 16:14:48.498  INFO 349004 --- [           main] com.hq.tk.TkApplication                  : The following profiles are active: dev

After trying to start it countless times, it appears: The following profiles are active: dev, which is about to crash. Later, I thought calmly that the parameters of the command line were received through the args parameters in the main function, and immediately went to see the startup class, sure enough.

1, springApplication. run does not pass in the args parameter

public static void main(String[] args) {
        SpringApplication springApplication = new SpringApplication(SsoApplication.class);
        // Monitoring life cycle 
        springApplication.addListeners(new SpringBootApplicationStartup());
        springApplication.run();
    }

Change

public static void main(String[] args) {
        SpringApplication springApplication = new SpringApplication(SsoApplication.class);
        // Monitoring life cycle 
        springApplication.addListeners(new SpringBootApplicationStartup());
        springApplication.run(args);
    }

Package and run again, and it appears: The following profiles are active: test

java -jar .\tk-provider.jar --spring.profiles.active=test
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/D:/softwareWorkspace/hqtx/HqService/ServiceProvider/tk-provider/target/tk-provider.jar!/BOOT-INF/lib/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/D:/softwareWorkspace/hqtx/HqService/ServiceProvider/tk-provider/target/tk-provider.jar!/BOOT-INF/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
====================> : Spring Boot  Initialize environment variables 

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.0.4.RELEASE)

2018-08-23 16:30:58.961  INFO 348708 --- [           main] com.hq.tk.TkApplication                  : Starting TkApplication v1.0-SNAPSHOT on longqin with PID 348708 (D:\softwareWorkspace\hqtx\HqService\ServiceProvider\tk-provider\target\tk-provider.jar started by Administrator in D:\softwareWorkspace\hqtx\HqService\ServiceProvider\tk-provider\target)
2018-08-23 16:30:58.964 DEBUG 348708 --- [           main] com.hq.tk.TkApplication                  : Running with Spring Boot v2.0.4.RELEASE, Spring v5.0.8.RELEASE
2018-08-23 16:30:58.966  INFO 348708 --- [           main] com.hq.tk.TkApplication                  : The following profiles are active: test