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

Allow alternative schema location in XsdBasedSoap11Wsdl4jDefinitionBuilder

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0 M3
    • Fix Version/s: 1.0.1
    • Component/s: Core
    • Labels:
      None

      Description

      I am using XsdBasedSoap11Wsdl4jDefinitionBuilder to generate WSDL for my schema.
      The schema itself imports another schema via a relative path:

      <xsd:import namespace="https://hyperjaxb2.dev.java.net/pows/po/schema" schemaLocation="../../po/schema/po.xsd"/>

      The WSDL itself is generated quite fine. However the schema itself is simply inserted into wsdl:types while schemaLocation in xsd:import remains the same. However, this location, when resolved against the wsdl location, points to an invalid URL.

      <?xml version="1.0" encoding="UTF-8"?>
      <wsdl:definitions ...>
      <wsdl:types>
      <xsd:schema ...>
      ...
      <xsd:import namespace="https://hyperjaxb2.dev.java.net/pows/po/schema" schemaLocation="../../po/schema/po.xsd"/>
      ...
      </xsd:schema>
      </wsdl:types>
      ...
      </wsdl:definitions>

      This problem can be easily resolved if instead of inserting the whole schema in wsdl:types we simply insert an xsd:schema with xsd:import pointing to the location of the actual schema. This location can be configured in the wsdl builder:

      <wsdl:definitions ...>
      <wsdl:types>
      <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <xsd:import
      namespace="https://hyperjaxb2.dev.java.net/pows/ws/schema"
      schemaLocation="resources/ws/schema/ws.xsd"/>
      </xsd:schema>
      </wsdl:types>
      </wsdl:definitions>

      I have implemented this solution based on the XsdBasedSoap11Wsdl4jDefinitionBuilder. Could you please review the code and maybe add this to the main code base.

        Issue Links

          Activity

          Hide
          lexicore Aleksei Valikov added a comment -

          Nice, thank you!

          Show
          lexicore Aleksei Valikov added a comment - Nice, thank you!
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          One issue with imports still remains. Suppose we have two schemas: A.xsd and B.xsd. A imports B. We register A.xsd with the XsdBasedSoap11Wsdl4jDefinitionBuilder , and use the schemaLocation property.

          All goes well when all the request and response elements are in A. However, when B also contains request and response elements that we want to base the WSDL on, it does not work, since the imported schema (B in this case) is not investigated.

          Aleksei, do you have any idea how to fix this?

          Show
          arjen.poutsma Arjen Poutsma added a comment - One issue with imports still remains. Suppose we have two schemas: A.xsd and B.xsd. A imports B. We register A.xsd with the XsdBasedSoap11Wsdl4jDefinitionBuilder , and use the schemaLocation property. All goes well when all the request and response elements are in A. However, when B also contains request and response elements that we want to base the WSDL on, it does not work, since the imported schema (B in this case) is not investigated. Aleksei, do you have any idea how to fix this?
          Hide
          lexicore Aleksei Valikov added a comment -

          Well, obviously it need to be investigated then. Why not simply recurse to the imported schema?

          The thing is, you follow a rather "syntactic" approach to the processing of XML Schema. Like, you grab all the xsd:elements, consider their names and build operations for those who follow certain naming conventions. It's not a deep kind of XML Schema processing: you don't process xsd:imports or xsd:includes or anything else like that.

          An alternative would be using something like XSOM to build and analyze the XML Schema object model. XSOM will handle includes and imports for you, you only need to find out which elements are responsible for requests and responses.

          Show
          lexicore Aleksei Valikov added a comment - Well, obviously it need to be investigated then. Why not simply recurse to the imported schema? The thing is, you follow a rather "syntactic" approach to the processing of XML Schema. Like, you grab all the xsd:elements, consider their names and build operations for those who follow certain naming conventions. It's not a deep kind of XML Schema processing: you don't process xsd:imports or xsd:includes or anything else like that. An alternative would be using something like XSOM to build and analyze the XML Schema object model. XSOM will handle includes and imports for you, you only need to find out which elements are responsible for requests and responses.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Yes, recursing into the imported schema is the option I also considered.

          Using a framework like XSOM is an interesting option, which relates to SWS-179

          Show
          arjen.poutsma Arjen Poutsma added a comment - Yes, recursing into the imported schema is the option I also considered. Using a framework like XSOM is an interesting option, which relates to SWS-179
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Closing 1.0.1 issues.

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

            People

            • Assignee:
              arjen.poutsma Arjen Poutsma
              Reporter:
              lexicore Aleksei Valikov
            • Votes:
              6 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: