Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-413

SchemaCollection issues with classpath resources and relative schema imports

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5.3, 1.5.4
    • Fix Version/s: 1.5.5
    • Component/s: OXM
    • Labels:
      None
    • Environment:
      Spring WS 1.5.3, war deployed to Jetty

      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)
      1. CommonsXsdSchemaCollection.java
        8 kB
        Patrick Crocker
      2. ClasspathBaseUriResolver.java
        2 kB
        Patrick Crocker

        Activity

        Hide
        patrick.crocker@gmail.com Patrick Crocker added a comment -

        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.

        Show
        patrick.crocker@gmail.com Patrick Crocker added a comment - 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.
        Hide
        patrick.crocker@gmail.com Patrick Crocker added a comment -

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

        Show
        patrick.crocker@gmail.com Patrick Crocker added a comment - CommonsXsdSchemaCollection - URIResolver set via dependency injection. ClasspathBaseUriResolver - find schemaLocation relative to baseUri.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        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...

        Show
        arjen.poutsma Arjen Poutsma added a comment - 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...
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

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

        Show
        arjen.poutsma Arjen Poutsma added a comment - Fixed. Feel free to try a snapshot as of tomorrow, and give it a go.
        Hide
        obillard Olivier Billard added a comment -

        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.

        Show
        obillard Olivier Billard added a comment - 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.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Closing old issues

        Show
        arjen.poutsma Arjen Poutsma added a comment - Closing old issues

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            patrick.crocker@gmail.com Patrick Crocker
          • Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: