Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to solve the error report when the Spring Boot project is deployed to the Linux server". In the daily operation, I believe that many people have doubts about how to solve the problem when the Spring Boot project is deployed to the Linux server. The editor consulted all kinds of information and sorted out a simple and easy-to-use operation method. I hope it will be helpful to answer the doubt that "how to solve the error report when the Spring Boot project is deployed to the Linux server". Next, please follow the editor to study!

A background

Recently in the Springboot development project A, cited the partner development module B, local service, running well, and so on deployed to the server, a run on the error: Caused by: java.lang.ClassNotFoundException.

Note: there are many reasons for this error, such as: package conflict, class conflict, package does not exist and so on. I will list only one of them here. After all, I have been cheating me for half a day, so I think it is necessary to share it.

Two reasons

Let's take a look at a strange phenomenon. I used another project C to quote the same dependency B, deployed to the server, running well, but not my project? Take a closer look:

1) Project C is deployed on the server, and the jar package under / app/C-service/lib is:

B-api-1.0.0-20191224.024308-5.jarB-dao-1.0.0-20191223.073120-2.jar

2) Project C is deployed on the server, / app/C-service/C-service.jar/META-INF/MANIFEST.MF, and the scanning path is:

Lib/B-api-1.0.0-20191224.024308-5.jarlib/B-dao-1.0.0-20191223.073120-2.jar

And:

1) my project An is deployed on the server, and the jar package under / app/A-service/lib is:

B-api-1.0.0-SNAPSHOT.jarB-dao-1.0.0-SNAPSHOT.jar

2) my project An is deployed to the server, / app/A-service/A-service.jar/META-INF/MANIFEST.MF, and the scanning path is:

Lib/B-api-1.0.0-20191224.024308-5.jarlib/B-dao-1.0.0-20191223.073120-2.jar

It is found that the path of the scanned jar package in MANIFEST.MF is inconsistent with the name of the actual decompressed jar package (one with a timestamp and the other is SNAPSHOT), so the jar packet cannot be scanned, resulting in an error: Caused by: java.lang.ClassNotFoundException.

So what is the cause of this tragedy? Coincidence of opportunity:

1. My partner's module uses SNAPSHOT when deploy, such as 1.0.0-SNAPSHOT. When I pull the jar package, I get: B-api-1.0.0-20191224.024308-5.jar:

Com.xxx.xxx B-api 1.0.0-SNAPSHOT

two。 My project A can run locally because at that time I didn't pack the mvn clean package-Dmaven.test.skip=true,IDEA local running project. When I ran the project locally, the scan path of the jar package was the same as the jar package actually pulled. When I packaged it and extracted the A-service.zip package, the local operation would also report an error.

3. The problem lies in the difference before and after the project An is packaged. Why is the name of the jar package in the lib/ directory decompressed by MANIFEST.MF and A-service.zip not the same?

4. Finally, by comparing the configuration file of project C with that of project A, the difference is found: project A has an additional line in the assembly.xml: ${artifact.artifactId}-${artifact.baseVersion}. ${artifact.extension}

${artifact.artifactId}-${artifact.baseVersion}. ${artifact.extension} false lib

5. If we get rid of this business, the problem has indeed been solved. But why? The jar package pulled down and the jar packet scanned in MANIFEST.MF with a time stamp always feel that there is something wrong with it. Then I looked for the relevant information with the word outputFileNameMapping, and sure enough, I found another big brother: false. This line of configuration is placed in the pom.xml of the project's Service module (the module where the Application.java startup class resides):

Org.apache.maven.plugins maven-jar-plugin 2.4true lib/ ${main.class} false * .yml * .properties

6. Explanation:

1) ${artifact.artifactId}-${artifact.baseVersion}. ${artifact.extension}, the function is when you pack: the jar package under lib/ can be renamed, for example, it should be BmerapiMe 1.0.0-20191224.024308-5.jar. After this line of configuration, the jar package is renamed to: B-api-1.0.0-SNAPSHOT.jar.

2) false, the function is that when you generate the MANIFEST.MF file, if the version of the jar package under lib/ is xxx-SNAPSHOT, should it be time stamped with a unique version? if you configure it as false (default is true), then it should be Bmurapi 1.0.0-20191224.024308-5.jar. After this line of configuration, the jar package is renamed to: B-api-1.0.0-SNAPSHOT.jar.

Just in time:

1) outputFileNameMapping,useUniqueVersions is not configured in project C, and the default value is used to make the name of the jar package under lib/ consistent with the name of the scanning path jar package under MANIFEST.MF (both with timestamps)

2) on the other hand, my project A, which not only copied the configuration files from somewhere, was equipped with outputFileNameMapping (without timestamp), but did not configure useUniqueVersions (with timestamp), resulting in inconsistency

So: these two configurations, either have or do not have, otherwise there will be inconsistencies, resulting in errors.

Three solutions

Personally, I think the jar package name is more elegant without a timestamp, so I recommend that outputFileNameMapping,useUniqueVersions be configured as follows:

Add configuration to 1.assembly.xml: ${artifact.artifactId}-${artifact.baseVersion}. ${artifact.extension}

${artifact.artifactId}-${artifact.baseVersion}. ${artifact.extension} false lib

two。 Add configuration to the pom.xml of the module where the startup class Application.java resides: false

Org.apache.maven.plugins maven-jar-plugin 2.4true lib/ ${main.class} false * .yml * .properties here On the "Spring Boot project deployment to the Linux server running error how to solve" the study is over, I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.