This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Comment

We didn't realise there was a runtime dependency on these schemas. It is obvious now, but looking at the number of examples which use the http location of the schemas we might just see a stack of production systems hit if they are restarted. In hindsight the schemas should be distributed with core Spring, or at least made available as part of the application rather than depending on Internet access.

Comment

We didn't realise there was a runtime dependency on these schemas. It is obvious now, but looking at the number of examples which use the http location of the schemas we might just see a stack of production systems hit if they are restarted. In hindsight the schemas should be distributed with core Spring, or at least made available as part of the application rather than depending on Internet access.

I only saw it this afternoon while trying to launch an application which uses OXM. If anyone cares:

e: I managed to get around this by ensuring I had updated all the schemaLocation versions to ones which had entries contained within the various META-INF/spring.schemas files that come with the spring JARs. It seems like the way schemaLocation works is by checking first whether specified location is valid, and if not, then checking the spring.schemas file to see if the XSD can be resolved from the classpath. In the event that the schema can be resolved from the classpath, you don't have failure to launch; however, if the version is missing from spring.schemas AND the URL is inaccessible, then you will see failure on startup.

The reason I was having problems with my application is because I was referencing an ancient v1.5 of the OXM schema, which was no longer contained in spring.schemas; hence failure. To fix this, I either left the version unspecified as part of the URI, or specified a version that was listed in the metadata and bundled with the JAR.

Comment

We didn't realise there was a runtime dependency on these schemas. It is obvious now, but looking at the number of examples which use the http location of the schemas we might just see a stack of production systems hit if they are restarted. In hindsight the schemas should be distributed with core Spring, or at least made available as part of the application rather than depending on Internet access.

Hi,

We have encountered this exact scenario in Production. Two of our WebSphere nodes have been restarted, however Spring MVC fails to launch our application.

It appears that in the Spring 3 spring.schemas files, only www.springframework.org has a mapping. Our app was written using Spring 2 originally, and recently has been upgraded to Spring 3, however we probably should have updated our xsd locations in our config files too.

So far, it appears that this might be our fix, but we haven't tested it well yet.

I haven't got the code in front of me, so can't post our exact changes.