A troubleshooting of Spring project packaging

A Spring project, which runs after jar package, is normal when there is a network, but once there is no network, an error will be reported. What's the matter? This article will record the troubleshooting process.


A graphical interface with a local database is required to be able to run in a non network environment. The graphical interface written by my friend in Java is not very beautiful, but it is better to be familiar with Java.

The project uses the idea's "Build Artifacts" package. After packaging, it runs normally. The interface and database access are normal. At first, it reported several errors, but later it didn't appear, and it didn't find the reason. That's what happened first.

Later, it was sent to others. It was impossible to open it at all. Like the previous error report, it seems that we must find out the reason for the error report.


Error content

First, post the error message:

Line 8 in XML document from class path resource [spring.xml] is invalid; 
nested exception is org.xml.sax.SAXParseException; 
lineNumber: 8; columnNumber: 76; 
cvc-elt.1: Element not found 'beans' Statement of.

spring.xml The code is intercepted as follows:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"

Problem recurrence

Because I have encountered this error report before, I want to repeat the problem for troubleshooting.

I run it directly in the virtual machine. It's OK whether it's an overlay installation or an uninstall and re installation. I think it's probably caused by environmental problems. I want to try wearing a new virtual machine.

After the new system is installed and running, it crashes as expected, with the same error message. To be able to reproduce problems can be said to be a good start in solving problems.


Find the reason

The search starts with the declaration of cvc-elt.1: element 'beans' not found. The search results are basically the following.

The xsd version information configured in the configuration file header is incorrect, causing an error in parsing. There are two steps to find the xsd or dtd verification file of the spring header. First, find it from the local jar package. If you find it, use the local jar package to check it (you can find it in spring-beans.jar Or spring-context.jar Under META-INF in spring.schemas xsd found in file If the file location is not found, the second step is to find it. It will try to download the file from the network and verify it. If the system is disconnected from the network or fails to download it, the above exception will be thrown.

According to this idea, my friend also reminded me to see if the virtual machine system is connected to the Internet. When I saw that it is not connected to the Internet, I quickly found that it can operate normally through networking test, and the cause of the problem was found.

Again confused

Finding the cause of the problem seems to be solved immediately, but the fact is not what I think.

The online solution is:

Will applicationContext.xml The version of xsd defined in the xsd file is changed to the version of xsd defined in the spring jar package. If the version definition is too high, it cannot be found locally and can only be downloaded from the network.

However, check out spring-beans.jar Under META-INF spring.schemas No matter what the version number is, the last point is one.

Some codes are intercepted as follows:


Later, I found an article Saxparse of spring5 Exception:cvc-elt.1 : Declaration of element 'beans' not found After Spring 5, you don't need to write the version number.

That's the same as what I saw. It's true that each version number points to the same one. It seems that it's not a version number problem. What's the matter?

striking one snag after another

Since the xsd version is right, what's the problem?

After continuing the search, I saw this article When the system starts, the spring configuration file fails to parse and reports "cvc-elt.1: Declaration" exception of element 'beans' not found」.

After packing, spring.schemas It is located in the META-INF directory of the jar package, but spring.schemas There's no spring in there- beans.xsd , it seems that the problem is here. I copy the author's method and put the spring mentioned above- beans.jar Under META-INF spring.schemas About spring in- beans.xsd Of is added to the spring.schemas Inside.

After repacking, it still reports an error, but it's not the previous one. It means that my main function class can't be found. It's really confusing. The situation is similar. Why can't I use it.

click into place

It's still the above operation. I asked my friend to give it a try. After the test, he could use it very well!

I asked him how to operate it. He said it's the same as my operation, but added the https part. I thought I shouldn't, and didn't reference the https spring-beans.xsd That's not the problem.

According to his operation, I repackaged my computer and found that it was still difficult to use; I replaced the file he gave me into my bag, but it was still difficult to use. It's really covered. The operation is the same. Why is it difficult for me to use it.

Later, my friend asked me to send the modified package to him. After he read it, he found that the size of the package I typed was different. Normally, it should be 14MB, but my package was 500KB. I operated it again, and found that after I replaced the file, the size of the whole jar package became smaller. It was my compression package software that had problems.

My friend's computer is Windows, which directly uses WinRAR to open the jar package, and then replaces the file; my computer is Mac, which uses eZip software to open the jar package, and then replaces the file. Finally, I used the virtual machine to follow my friend's operation and found that it was ok.

Who could have expected the problem of compression software? But we can't blame all the software. After all, people decompress the software, not specially deal with jar files.

Perfect solution

Although the cause of the problem has been found and the solution has been found, the solution is not good enough. Can't you replace the file manually every time you have a good package?

I think since we can meet problems, there must be others, I will use keywords spring.schemas After packing, I didn't type beans in to search, and found the perfect solution: spring packaging to jar problem」.

The root cause of the problem is that multiple jar packages in spring contain spring.schemas By default, "Build Artifacts" and "Maven" package only the first encountered schema file into the jar package.

The solution is to use maven shade for packaging. The specific code is as follows:

                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                    <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                    <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                    <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">

Put code in project pom.xml In the < plugins > node of the code, the complete directory of the main function should be written in the < mainclass > node.


The problem has been solved and some feelings have been gained from it:

  • If you have a problem, you have to solve it as soon as possible, because it won't let you go.
  • The compression software under Mac is not as good as that under Windows.
  • The answer on the Internet is really the same. It's a person's answer that has been copied by many people, and the question has not been explained clearly.
  • The same answers we found may be outdated and not suitable for our own situations.
  • Most of the problems that you encounter are those that others have encountered and can be solved. If you search patiently, you will find a solution.

Welcome to personal blog: Grave digger's shovel</mainclass></plugins>

Tags: Programming Spring xml Maven network

Posted on Mon, 01 Jun 2020 00:56:38 -0400 by Ozzapoo