[SWS-413] SchemaCollection issues with classpath resources and relative schema imports Created: 12/Aug/08  Updated: 04/May/12  Resolved: 28/Aug/08

Status: Closed
Project: Spring Web Services
Component/s: OXM
Affects Version/s: 1.5.3, 1.5.4
Fix Version/s: 1.5.5

Type: New Feature Priority: Minor
Reporter: Patrick Crocker Assignee: Arjen Poutsma
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Spring WS 1.5.3, war deployed to Jetty


Attachments: Java Source File ClasspathBaseUriResolver.java     Java Source File CommonsXsdSchemaCollection.java    

 Description   

This issue is linked to the following thread http://forum.springframework.org/showthread.php?p=176210

I store my schemas in a specific maven project together with the generated sources.

client-messages.xsd import client-types.xsd

In my war project, I configured the Spring-WS config file this way:

<bean id="schemaCollection" class="org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection">
<property name="xsds">
<list>
<value>classpath:client-messages.xsd</value>
</list>
</property>
<property name="inline" value="true" />
</bean>

When generating the wsdl, the framework complains that the client-types.xsd is not found.

Would it be possible to enhance the XsdSchemaCollection (or to write a specific org.apache.ws.commons.schema.resolver.URIResolver) which can handle the import nicely ?

Workaround is twofolds:

  • put the xsds in the war file
  • merge the xsds in one single file (no more import statement)


 Comments   
Comment by Patrick Crocker [ 12/Aug/08 ]

This is a clone of SWS-362 http://jira.springframework.org/browse/SWS-362.

The fix introduced in spring-ws-1.5.4 only satisfies xsd's found at the root of the classpath. The issue is not resolved with respect to xsd files located in packages.

Example:
org/example/schema/messages.xsd
org/example/schema/types.xsd

File messages.xsd uses an import with a relative URL:
<xsd:import namespace="http://www.example.org/schema/types" schemaLocation="types.xsd" />

This issue could be resolved by attempting to find the imported schema relative to the baseUri value (as shown at http://forum.springframework.org/showpost.php?p=189478&postcount=14 by blackbeltdev).

Additionally, if the CommonsXsdSchemaCollection class was open to having the URIResolver set via dependency injection, users could create their own URIResolver for special cases.

I've attached a modified version of CommonsXsdSchemaCollection that allows DI of the URIResolver (defaults to the private ClasspathUriResolver) and a new ClasspathBaseUriResolver class that merges the ClasspathUriResolver with the baseUri lookup code demonstrated by blackbeltdev on the forum.

Comment by Patrick Crocker [ 12/Aug/08 ]

CommonsXsdSchemaCollection - URIResolver set via dependency injection.
ClasspathBaseUriResolver - find schemaLocation relative to baseUri.

Comment by Arjen Poutsma [ 28/Aug/08 ]

Thanks for the code! Wouldn't it be better to use the ClasspahBaseUriResolver as default, rather than the private ClasspathUriResolver one? It seems like its logic s useful in most cases....

I will make the UriResolver settable in any case...

Comment by Arjen Poutsma [ 28/Aug/08 ]

Fixed. Feel free to try a snapshot as of tomorrow, and give it a go.

Comment by Olivier Billard [ 12/Jan/10 ]

For information, this fix only works for XSD files in the same physical classpath location (WEB-INF/classes, the same JAR file), but not in several JAR artifacts. In that last case, the base URI is different.

SWS-594 fixes this.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sun Dec 17 21:32:52 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.