Spring XSD file URLs are not accessible
Article ID: 338937
Updated On:
Products
VMware
Issue/Introduction
Symptoms:
- A Spring-enabled application fails to start and shows one or more errors in the logs.
- The errors may be 403 or 404 errors if the schema cannot be found at the specified network location.
- You see messages in the log similar to:
WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored XML validation warning
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document '/spring-beans-3.1.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>
Environment
Spring Framework 2.5
Spring Framework 3.0
Spring Framework 3.1
Spring Framework 3.0
Spring Framework 3.1
Cause
The schema that was referenced in a Spring configuration file could not be located in any of the deployed jars or at the network path specified in the configuration file. This usually occurs when the configuration file specifies a version of the schema that is a later version than the deployed Spring jars.
When the context loads, the preferred location for the schema is always from the application classpath. Since each Spring module bundles the schemas from all earlier versions, as long as the version deployed with the application is the same or newer than what is specified in the configuration file, the correct schema will be loaded.
If the correct schema is not found on the classpath and if there is some issue with accessing that same version from the network, the application will fail to bootstrap properly.
This usually occurs when copying an example built with a later version of a project, then deploying it with an older version. The application may still compile and run correctly in development. The error then appears after moving to production, where there may be more restrictive network access which prevents the newer schema from being accessed from the remote location.
When the context loads, the preferred location for the schema is always from the application classpath. Since each Spring module bundles the schemas from all earlier versions, as long as the version deployed with the application is the same or newer than what is specified in the configuration file, the correct schema will be loaded.
If the correct schema is not found on the classpath and if there is some issue with accessing that same version from the network, the application will fail to bootstrap properly.
This usually occurs when copying an example built with a later version of a project, then deploying it with an older version. The application may still compile and run correctly in development. The error then appears after moving to production, where there may be more restrictive network access which prevents the newer schema from being accessed from the remote location.
Resolution
This issue is best remedied by using "schemaless" XSDs. For example, use spring-beans.xsd instead of spring-beans-3.1.xsd.
The prior XSD is always mapped to the current version of the schema within your Spring jars, so it will continue to work across upgrades.
Note: If you want to use an attribute that has been deprecated in the current jar's version, you can use the numbered XSD. This could cause future issues due to version mismatch, however.
The prior XSD is always mapped to the current version of the schema within your Spring jars, so it will continue to work across upgrades.
Note: If you want to use an attribute that has been deprecated in the current jar's version, you can use the numbered XSD. This could cause future issues due to version mismatch, however.
Feedback
Yes
No
Powered by
