Нет необходимости использовать протокол classpath: в URL-адресе schemaLocation, если пространство имен настроено правильно и XSD-файл находится в вашем пути к классам.
Spring doc " Регистрация обработчика и схемы " показывает, как это должно быть сделано.
В вашем случае проблема, возможно, заключалась в том, что jar с контекстным контекстом на вашем пути к классам не был 2.1. Вот почему изменение протокола на classpath: и установка специфического XSD 2.1 в вашем classpath устранила проблему.
Из того, что я видел, есть две схемы, определенные для основного XSD, содержащиеся в банке spring- *. Один раз для разрешения URL-адреса схемы с версией и один раз без нее.
В качестве примера посмотрите эту часть содержимого spring.schemas в spring-context-3.0.5.RELEASE.jar:
http\://www.springframework.org/schema/context/spring-context-2.5.xsd=org/springframework/context/config/spring-context-2.5.xsd
http\://www.springframework.org/schema/context/spring-context-3.0.xsd=org/springframework/context/config/spring-context-3.0.xsd
http\://www.springframework.org/schema/context/spring-context.xsd=org/springframework/context/config/spring-context-3.0.xsd
Это означает, что (в xsi: schemaLocation)
http://www.springframework.org/schema/context/spring-context-2.5.xsd
будет проверен на соответствие
org/springframework/context/config/spring-context-2.5.xsd
в пути к классам.
http://www.springframework.org/schema/context/spring-context-3.0.xsd
или
http://www.springframework.org/schema/context/spring-context.xsd
будет проверено на соответствие
org/springframework/context/config/spring-context-3.0.xsd
в пути к классам.
http://www.springframework.org/schema/context/spring-context-2.1.xsd
не определено, поэтому Spring будет искать его, используя литеральный URL, определенный в schemaLocation.