Spring configuration XML schema: with or without version?

I am new to Spring. One thing confuses me is that sometimes I see XML configuration files with versioned schemas, yet sometimes with non-versioned ones. For example, sometimes I see something like

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-4.0.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context-4.0.xsd">

    <context:annotation-config/>

    <context:component-scan base-package="base.package"/>

</beans>

And sometimes like this:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context.xsd">

    <context:annotation-config/>

    <context:component-scan base-package="base.package"/>

</beans>

Note that the spring-beans and spring-context schemas are different in the two examples.

So, my question is, which style would you use and why? In particular, will the versioned schema become unavailable in the future, and will the non-versioned schema keep compatible with a current application when Spring updates the schema?

A side question is, where can I find a list of the versioned spring schemas?

Many thanks!

Solution 1:

It is recommended to use the "versionless" XSDs, because they're mapped to the current version of the framework you're using in your application.

Applications and tools should never try to fetch those XSDs from the web, since those schemas are included in the JARs. If they do, it usually means your app is trying to use a XSD that is more recent than the framework version you're using, or that your IDE/tool is not properly configured.

To my knowledge, there's only one case where you'd want to use specific XSD versions: when trying to use a XML attribute that's been deprecated/modified in a more recent version. That doesn't happen often to say the least.

Anyway the Spring team should drop the versioned schemas for Spring 5.0, see SPR-13499.

More on "versionless == current version":

Those XSD files are included in Spring JARs - the "versionless" XSD is mapped to the latest version during the build (see the spring.schemas files that actually make that link). Also, the files available online are built the same way (see the "schemaZip" target in the gradle build).

Solution 2:

I am not sure if their is a guidance, but my personal preference is to refer to the non-versioned schemas - in general if you are working against the more recent versions of the Spring projects(Spring core, integration etc), then you can refer to the unversioned schemas.

The unversioned schemas point to the latest version of the projects so it is possible that they may not be the correct grammar if you are using really old version of Spring (say version 2.5 against currently released 4.0 version), in such cases it may be better to point to the versioned schemas.

One more point to make here is that if possible it is better to avoid xml altogether and go with Java based @Configuration style to configure your Spring beans.

Solution 3:

I know that the question is over two years old, but my take is to proceed with caution.

In my case I was developing a stand-alone CLI tool, a jar of jars. And when my declared XSDs were versionless(sic), I would notice very strange errors. Consider the following xml fragment:

Without the versions, the value-separator attribute in the property placeholder will cause the following error:

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 22 in XML document from class path resource [META-INF/slitools/sli-cli-applicationContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'value-separator' is not allowed to appear in element 'context:property-placeholder'.
    at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:399)

One could try to see what on earth is being pulled via transitive dependencies (even though careful inspection showed we were pulling the right jars containing the right xsds (and ensured we were doing the right property merging with the shade plugin when we were building the uber-jars.)

Obviously YMMV. If it works for one project, the better. But if you ever start seeing strange errors that defy explanation and you do not have the bandwidth to chase them down to the root cause, better to be precise.

The counter-argument of this is that if you ever change the version of your spring dependencies, you need to make sure the explicit xsd version are correct. In software, it is all about trade-offs (and knowing what you get into with your decisions.)