Spring WS: CommonXsdSchemaCollection fails to resolve XSDs imported with relative path like "../common.xsd"

[Skrrytch]

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);
} else {
  // Try relative to baseUri ...
}

If schemaLocation is "../common.xsd" then resource.exists() fails with the above exception thrown by the internal call to RequestUtils.normalize("/../common.xsd"). So the following else-statement is never executed.

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) 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!

[snicoll]

Thanks for the sample. I wonder if what's going on is related to some path traversal protection. I'll give it a proper look based on your sample.

[snicoll]

@bclozel and I had a look to the sample. It's an interesting problem where the semantic of the import is a bit blurry IMO. The value of the import can be resolved as:

. A raw absolute resource based on its name, using the ResourceLoader
. A URL resource that's relative to the baseURI provided
. A classpath resource

Unfortunately, the sample above is asking /../common.xsd as a servlet resource and that'll fail. We could change the logic but I wonder how impactful that's going to be. Perhaps a new implementation could help with that. We'll think some more.