Spring Loading XSD file

Sometimes you will find that the past has been started normal system, one day when the startup will report the shape of the following error:

[plain] view plain copy org.xml.sax.saxparseexception:schema_reference.4:failed to read schema document ' http: Www.springframework.org/schema/beans/spring-beans-2.0.xsd ', because 1) could not find the document; 2) The document could not be read; 3) The root element of the document is not <xsd:schema>.
Obviously, the XSD file specified in the spring XML configuration file cannot be read because it is caused by a temporary inability to connect to the Web or spring's official website. You can confirm by entering the URL of the XSD file in the browser, such as: Http://www.springframework.org/schema/beans/spring-beans-2.0.xsd.

On this issue, there are two common solutions on the Web, the first one is simple and effective, but the workload is large, that is, to convert all the XSD paths in the form of the URL in the spring configuration file into the Classpath form of the local XSD file exponentially, for example: classpath:org/ Springframework/beans/factory/xml/spring-beans-2.5.xsd, another way is to build a Web server in this machine, create the appropriate folder by URL, put in the corresponding XSD file, in the native Hosts file to add "127.0.0.1 www.springframework.org". In fact, both of these methods belong to the "fluke" approach, and it is clear that the problem needs to be discussed from the spring XSD file loading mechanism.

First of all: you have to know thatspring always tries to find the XSD file locally when loading the XSD file (the Spring jar package already contains all versions of the XSD file), and if it is not found, it will be diverted to the path specified by the URL to download. This is a very reasonable approach, not as it seems, every time it is downloaded from the site. In fact, if all your configurations are being determined, your project can be launched without the error on the network. Spring load XSD File class is pluggableschemaresolver, you can look at its source code to verify the above statement. Alternatively, you can include the following in the Log4j.xml file:

[HTML] view plain copy <logger name= "Org.springframework.beans.factory.xml" > <level value= "All"/ > </logger>
The log understands that spring is a finer xsd file.

Next, the question is why spring does not find the required files locally and has to go to the website to download. In fact, it's very simple. In many spring jar packages, there is a spring.schemasin the Meta-inf directory, which is a property file with the contents similar to the following:

[plain] view plain copy http\://www.springframework.org/schema/beans/spring-beans-2.0.xsd=org/ Springframework/beans/factory/xml/spring-beans-2.0.xsd http\://www.springframework.org/schema/beans/ Spring-beans-2.5.xsd=org/springframework/beans/factory/xml/spring-beans-2.5.xsd http\://www.springframework.org /schema/beans/spring-beans-3.0.xsd=org/springframework/beans/factory/xml/spring-beans-3.0.xsd ....
In fact, this file is spring's map of the XSD file's local storage path, which spring uses to find the XSD file locally (that is, the spring jar). Then, if you do not find a reason to exclude the wrong URL input, it is possible that the declared XSD file version does not exist locally. In general, the new version of the Spring jar package will package the XSD of all previous versions (which should be since 2.0). And in the Spring.schemas file to add the corresponding entries, the situation is often the case that a high version of the XSD file is declared, such as 3.0, but the dependent Spring jar package is a 2.5 version, because the 2.5 version naturally cannot contain 3.0 XSD files, this will cause spring to go The problem occurs when a site downloads a target XSD file, such as a broken network or a target site that is unavailable.

However, in the implementation of development, the probability of these errors is not high, the most common cause of this problem is actually the use of a maven called "Assembly" of the package plug-in. Many projects need to package the project with all the jar packages on which it relies, and the MAVEN assembly plugin is used to accomplish this task. But because engineering often relies on a lot of jar packages, and the dependent jars are dependent on other jar packages, when the project relies on different versions of spring, when using assembly to package, Only the Spring.schemas file under one version jar package can be placed in the final jar package, it is possible to omit some version of the XSD local mapping, and then the article began to mention the error. If your project is a single jar, you can verify that this is not the case by checking the Spring.schemas file in the resulting jar. In this case, the solution is generally recommended to use another package plugin shade, which is indeed a better tool than Assembly, On spring.schemas file processing, shade is able to merge all the Spring.schemas files in the jar, and in the resulting single jar, Spring.schemas contains a collection of all the versions that have appeared.

The above is the mechanism of spring loading XSD file and the cause analysis of the problem. In fact, we should let our project always load the local XSD file at startup, rather than every time we go to the site to download, this will require you to combine the above mentioned conditions to carry out a review of your project.