Introduction

This error usually means Spring found the XML namespace declaration but could not find the Java code that knows how to parse the security tags. In practice, that almost always points to a missing spring-security-config JAR, a version mismatch between Spring modules, or an XML file that declares the namespace incorrectly.

What the NamespaceHandler Error Really Means

When Spring parses XML configuration, each custom namespace is backed by a NamespaceHandler. For Spring Security XML, that handler is packaged in the Spring Security configuration module, not in Spring Core itself.

So this message is not about the XSD being unreachable on the internet. It is usually about the classpath. Spring loads handlers from metadata inside the JARs, especially META-INF/spring.handlers and related parser registrations.

If the right security configuration JAR is absent, Spring can resolve the XML namespace string but still fail when it tries to instantiate the handler.

The First Thing to Check: Dependencies

For XML-based Spring Security configuration, the critical artifact is typically spring-security-config, along with the rest of the matching Spring Security modules.

A Maven example:

1<dependencies>
2    <dependency>
3        <groupId>org.springframework</groupId>
4        <artifactId>spring-context</artifactId>
5        <version>3.0.7.RELEASE</version>
6    </dependency>
7
8    <dependency>
9        <groupId>org.springframework.security</groupId>
10        <artifactId>spring-security-config</artifactId>
11        <version>3.0.7.RELEASE</version>
12    </dependency>
13
14    <dependency>
15        <groupId>org.springframework.security</groupId>
16        <artifactId>spring-security-web</artifactId>
17        <version>3.0.7.RELEASE</version>
18    </dependency>
19</dependencies>

The important part is version alignment. Mixing one Spring Security release with unrelated Spring framework versions is a reliable way to produce namespace or parser failures.

Verify the XML Namespace Declaration

The next check is the XML itself. A typical Spring Security configuration file needs the security namespace and schema location to be declared correctly.

1<beans:beans
2    xmlns="http://www.springframework.org/schema/security"
3    xmlns:beans="http://www.springframework.org/schema/beans"
4    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
5    xsi:schemaLocation="
6        http://www.springframework.org/schema/beans
7        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
8        http://www.springframework.org/schema/security
9        http://www.springframework.org/schema/security/spring-security-3.0.xsd">
10
11    <http auto-config="true">
12        <intercept-url pattern="/**" access="ROLE_USER" />
13        <form-login />
14    </http>
15
16    <authentication-manager>
17        <authentication-provider>
18            <user-service>
19                <user name="user" password="password" authorities="ROLE_USER" />
20            </user-service>
21        </authentication-provider>
22    </authentication-manager>
23</beans:beans>

Small typos in the namespace URI or in the schema location are enough to trigger confusing parser errors.

Check for Classpath Collisions

Older Spring applications often carry libraries manually in WEB-INF/lib, through IDE containers, or via partial Maven migration. That makes duplicate or conflicting JARs common.

If you use Maven, inspect the dependency tree:

mvn dependency:tree | grep spring

If you do not use Maven, inspect the deployed WAR contents directly. One stray older Spring Security JAR can override the one you thought you were using.

A Useful Diagnostic Shortcut

If you suspect the correct module is missing, open the spring-security-config JAR and look for Spring namespace metadata. The exact file names matter more than guessing.

jar tf spring-security-config-3.0.7.RELEASE.jar | grep spring.handlers

If that metadata is absent or the JAR is not on the runtime classpath, Spring has no handler to load.

Common Pitfalls

The most common mistake is adding spring-security-core and assuming that is enough for XML namespace support. It is not. The XML parser support lives in spring-security-config.

Another issue is mixing Spring and Spring Security versions loosely. Namespace parsing is sensitive to classpath compatibility.

A third problem is assuming the error means the XSD URL must be reachable over the network. Spring typically resolves this through packaged metadata, so classpath issues are the real target.

Summary

• This error usually points to a classpath problem, not an internet problem.
• Make sure spring-security-config is present for XML-based security configuration.
• Keep Spring Framework and Spring Security versions aligned.
• Verify the namespace URI and xsi:schemaLocation values carefully.
• Inspect the runtime classpath or dependency tree if the XML still looks correct.