Context: spring-boot-starter-parent 3.4.1 Sample project: https://github.com/Skrrytch/SpringWS-XsdSchemaCollection-Fix

The problem:

The sample project provides a SOAP web service via SpringWS. It uses some XSDs organized as follows:

  • /xsd/common.xsd
  • /xsd/order/order.xsd (imports "../common.xsd")
  • /xsd/order/order-webservice.xsd (imports "order.xsd")

Since multiple XSDs are responsible for the final web service, we configure the WsdlDefinition with a CommonXsdSchemaCollection which should resolve all used XSDs. This works very well as long as no relative import of “common.xsd” is used in our “order.xsd”.

For an import of "../common.xsd" the default classpath uri resolver of CommonXsdSchemaCollection fails with:

java.lang.IllegalArgumentException: The resource path [/../common.xsd] has been normalized to [null] which is not valid

The cause

The problem lies in the following code snippet of CommonXsdSchemaCollection::ClasspathUriResolver:

Resource resources = resourcesLoader.getResource(schemaLocation);
if (resource.exists()) {
   return createInputSource(resource);
}

If schemaLocation is "../common.xsd" then resource.exists() fails with the above exception thrown by the internal call to RequestUtils.normalize("/../common.xsd").

About this sample project

The current state of this project will throw the exception when starting the application:

mvn clean install
mvn spring-boot:run

We have implemented a workaround in SpringWsConfig:90 (FixedClasspathUriResolver class) which can be activated in SpringWsConfig:74. It solves this problem by catching the exception and executing the else section which then resolves the storage location relatively to the baseUri. This also shows that the existing fallback for relative paths works like a charm!


This is my first bug report here. I couldn't find a similar bug report and hope the information is enough. Otherwise, feel free to ask again!