Tag Archives: eclipse configuration

The Spring problem Failed to read Schema Document 

schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans-2.5.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>.

One solution: Cut and paste the code and save it.

Sometimes you will find that a system that has been booting up properly in the past will one day report the following error:

(plain)
view plain
The copy

    org. XML, sax SAXParseException: schema_reference. 4: Failed to read the 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, mostly due to an outage or the temporary inability to connect to the Spring official website. You can use the browser type XSD file URL, such as: http://www.springframework.org/schema/beans/spring-beans-2.0.xsd for confirmation.

    There are two common online solutions to this problem. The first is simple and effective, but cumbersome: convert all spring configuration files with XSD paths in the form of urls to paths in the form of CLASspath pointing to local XSD files, for example: Classpath: org/springframework/beans/factory/XML/spring beans – 2.5 XSD, another way is to build in the native web server, according to the URL to create the corresponding folder, in a corresponding XSD file, add “127.0.0.1 www.springframework.org” in the machine hosts file. In fact, both of these approaches are “skew” approaches, and to figure this out you need to start with Spring’s XSD file loading mechanism.

    First of all: You must know that Spring always tries to look up the XSD file locally when it loads the XSD file (all versions of the XSD file are already included in the Spring JAR), and if it is not found, then it will go to the URL specified path to download. This is a perfectly reasonable thing to do, and it doesn’t look like it’s downloaded from the site every time. In fact, if all of your configurations are positive, your project can be started without an error if the network is disconnected. Spring load XSD file class is PluggableSchemaResolver, you can take a look at its source to verify the above statement. In addition, you can add in log4j.xml:

    [HTML]
    view plain
    The copy

      < The logger name = “org. Springframework. Beans. Factory. XML” & gt; & lt; Level value = “all”/& gt; & lt; /logger>

      Log to see how Spring loads XSD files.
      Next, the question is why Spring didn’t find the required files locally and had to go to the web site to download them. And this is a very simple question. In many Spring JARS, under the meta-INf directory, there is a Spring.schemas, this is a property file, the contents of which are like the following:

      (plain)
      view plain
      The copy

      The

        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 location path of the XSD file that Spring USES to find the XSD file locally (that is, in spring’s JAR). The reason for not finding the XSD file may be that the version of the declared XSD file does not exist locally, other than the URL typing error. In general, the new version of the spring jar package will all the past version (2.0) should be self XSD packaging, and in the spring. The schema file to add the corresponding item, the situation of the problems are often the statement USES a high version of the XSD file, such as 3.0, but rely on the spring jar package is the previous version 2.5, due to the nature not may contain 3.0 2.5 XSD file, at this time will cause the spring to XSD file target site to download, in case of broken network or target site is not available, That’s what happened.

        However, in implementation development, these errors are not uncommon, and the most common cause of this problem is related to the use of a Maven packaging plug-in called “Assembly.” Many projects need to package the project together with all the JARS it depends on into a jar package, and Maven’s Assembly plug-in is designed to do this. But because the engineering often rely on many jars, and be dependent jar can rely on other jar package, so that when the project rely on to a different version of the spring, when using the assembly for packaging, can only be one version under the jars of spring. The schemas files into finally hit the jar of the bag, it’s likely missing out on some version of the XSD local map, then the article mentioned at the beginning of the error. If your project is a single JAR, you can verify that this is not the case by examining the Spring.schemas file in the resulting JAR. In this case, the solution is generally recommended to use another packaged plug-in shade, which is indeed a more excellent tool than assembly. On the processing of Spring.schemas file, shade can merge all the Spring.schemas files in all jars.

        This is the mechanism by which Spring loads XSD files and the analysis of the cause of the problem. In fact, we should have our project always load a native XSD file at startup, rather than download it every time we go to the site, which requires a review of your project in the context of the above.
        In this paper, the original link: http://blog.csdn.net/bluishglc/article/details/7596118, reprint please indicate the source!

        Through baidu and search, I found that it was caused by the mismatch between the version and configuration of spring That I relied on in Maven POM.xml.
        I used
        &lt in the pom.xml; spring.version> 4.0.9. RELEASE< /spring.version>
        USES version 4.0, but the above is version 3.1
        . Change the spring configuration in the above screenshot to 4.0, and do a clean operation at the same time, the problem is solved