Spring load XSD File

Sometimes you may find that a system that has been activated in the past has been launched on a certain day with 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 is read; 3) The root element of the document is not <xsd:schema>.
Obviously, the XSD file specified in the spring XML configuration file could not be read, due to the disconnect or the spring's web site temporarily unreachable. 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, one that is simple and effective, but with a lot of work, that is, converting a URL-form XSD path in all spring configuration files to a classpath-form path to a local XSD file, for example: classpath:org/exponentially 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 the corresponding XSD file, in the local hosts file to join "127.0.0.1 www.springframework.org". In fact, both of these methods are "fluke" methods, and it is clear that the problem also needs to be discussed from the spring XSD file loading mechanism.

First: You have to know one thing:Spring always tries to locate an XSD file locally when it loads the XSD file (all versions of the XSD file already contained in spring's jar package), and if it is not found, it will go to the path specified by the URL to download. This is a very reasonable approach and it is not as it seems to be downloaded from the site every time. In fact, if all of your configurations are positive, your project can be started with a disconnected network and will not report the above error. The class that spring loads an XSD file is pluggableschemaresolver, and you can check its source to verify the above statement. Alternatively, you can add in the Log4j.xml file:

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

Next, the problem is why spring does not find the required files locally and has to move to a Web site to download. In fact, this question is very simple. In many spring jar packages, there is a spring.schemasin the Meta-inf directory, which is a property file that resembles 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 mapping of the local path of the XSD file, which spring is looking for in the local (that is, spring jar) to find the XSD file. Then, the reason for not finding the exclusion URL input is incorrect, may be the declared XSD file version does not exist locally. In general, the new version of the Spring jar package will package XSD versions of all previous releases (which should be since 2.0), and add the corresponding entry in the Spring.schemas file, the problem is often that the declaration uses a high version of the XSD file, such as 3.0, but the dependent Spring jar package is 2.5 before the version, since the 2.5 version naturally cannot contain 3.0 XSD files, this will cause spring to Site to download the target XSD file, such as in the event of a broken network or the target site is not available, the above problems occurred.

However, the probability of this error is not high in implementing development, and the most common cause of this problem is related to the use of a maven packaged plug-in named "Assembly." Many projects need to be packaged into a jar package with all of the jar packages on which it relies, and MAVEN's assembly plug-in is used to accomplish this task. But because engineering often relies on a lot of jar packages, the dependent jar relies on other jar packs, so that when the project relies on different versions of spring, when it is packaged with assembly, Only one version of the Spring.schemas file under the jar package can be placed in the final jar package, which may omit some version of the local mapping of the XSD, and then the error that the article starts to mention. If your project is made into a single jar, you can verify that this is the case by checking the Spring.schemas file in the resulting jar. In this case, the solution is generally recommended to use another packaged plug-in shade, it is indeed a better than the Assembly tool, On the Spring.schemas file processing, shade is able to merge all the Spring.schemas files in the jar, in the final generation of a single jar package, Spring.schemas contains a collection of all occurrences of the version.

The above is the mechanism of spring loading XSD files and the cause analysis of the problems. In fact, we should get our project to always load the local XSD file at startup instead of every time we go to the site to download it, which requires you to check your project in conjunction with the above mentioned situations.