Woden
  1. Woden
  2. WODEN-5

The WSDLReader should offer more methods to parse WSDL documents from dom, sax, etc...

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Parser
    • Labels:
      None
    1. readWSDL.patch
      7 kB
      Guillaume Nodet

      Activity

      Hide
      Guillaume Nodet added a comment -

      This patch add several methods to the WSDLReader interface and their implementations.
      The missing one is the one that take a WSDLLocator.

      Show
      Guillaume Nodet added a comment - This patch add several methods to the WSDLReader interface and their implementations. The missing one is the one that take a WSDLLocator.
      Hide
      Guillaume Nodet added a comment -

      Is there anything missing for this patch to be included ?
      Please tell me and i'd be glad to work on it ...

      Show
      Guillaume Nodet added a comment - Is there anything missing for this patch to be included ? Please tell me and i'd be glad to work on it ...
      Hide
      Lawrence Mandel added a comment -

      John, can you handle this in M5?

      Show
      Lawrence Mandel added a comment - John, can you handle this in M5?
      Hide
      John Kaputin added a comment -

      Yes, I'll handle this in M5.

      Show
      John Kaputin added a comment - Yes, I'll handle this in M5.
      Hide
      John Kaputin added a comment -

      I have committed code to support reading WSDL from other formats such
      as a DOM Element or Document or an InputSource, however I have not used
      methods like readWSDL(String, Element) on WSDLReader.

      I did not want to simply add to the WSDLReader interface WSDL4J-like
      methods such as readWSDL(String, Element) or readWSDL(String, Document)
      because this would make the WSDLReader API dependant on DOM which defeats
      one of Woden's objectives for supporting different types of XML parser
      and XML object model without tying the Woden API to any particular one.

      Instead I have create an API interface called org.apache.woden.WSDLSource
      which stores the WSDL source object and the document base URI. A WSDLSource
      object is obtained by calling the WSDLReader.createWSDLSource() method.
      The WSDLSource setSource and setBaseURI methods are called before invoking
      WSDLReader.readWSDL(WSDLSource) or readWSDL(WSDLSource, ErrorHandler).

      WSDLSource.setSource(java.lang.Object) trades compile time type safety for
      XML parser independence in the Woden API. The WSDLSource implementation
      should provide runtime time type checking in its setSource method.
      The concrete reader's implementation of the createWSDLSource() method will
      return an implementation of WSDLSource compatible with the reader. That is,
      one that will perform runtime type checking in the setSource method to
      ensure the source Object is of a type compatible with the reader, and
      throw a WSDLException if it's not.

      Here's a progamming example based on the existing DOM reader implementation:

      WSDLSource wsdlSource = domReader.createWSDLSource();
      wsdlSource.setBaseURI(wsdlURI);
      //type checking of compatible object types done next
      wsdlSource.setSource(domElement);
      DescriptionElement desc = reader.readWSDL(wsdlSource);

      The Javadoc of WSDLReader and WSDLSource provide further information.

      An alternative option was to capture these methods in a DOM-specific Woden API,
      like an API subset, but this suggests making some parts of the overall Woden API
      optional to implementors (i.e. to a StAX implementor) and this approach
      probably requires more thought and discussion.

      Show
      John Kaputin added a comment - I have committed code to support reading WSDL from other formats such as a DOM Element or Document or an InputSource, however I have not used methods like readWSDL(String, Element) on WSDLReader. I did not want to simply add to the WSDLReader interface WSDL4J-like methods such as readWSDL(String, Element) or readWSDL(String, Document) because this would make the WSDLReader API dependant on DOM which defeats one of Woden's objectives for supporting different types of XML parser and XML object model without tying the Woden API to any particular one. Instead I have create an API interface called org.apache.woden.WSDLSource which stores the WSDL source object and the document base URI. A WSDLSource object is obtained by calling the WSDLReader.createWSDLSource() method. The WSDLSource setSource and setBaseURI methods are called before invoking WSDLReader.readWSDL(WSDLSource) or readWSDL(WSDLSource, ErrorHandler). WSDLSource.setSource(java.lang.Object) trades compile time type safety for XML parser independence in the Woden API. The WSDLSource implementation should provide runtime time type checking in its setSource method. The concrete reader's implementation of the createWSDLSource() method will return an implementation of WSDLSource compatible with the reader. That is, one that will perform runtime type checking in the setSource method to ensure the source Object is of a type compatible with the reader, and throw a WSDLException if it's not. Here's a progamming example based on the existing DOM reader implementation: WSDLSource wsdlSource = domReader.createWSDLSource(); wsdlSource.setBaseURI(wsdlURI); //type checking of compatible object types done next wsdlSource.setSource(domElement); DescriptionElement desc = reader.readWSDL(wsdlSource); The Javadoc of WSDLReader and WSDLSource provide further information. An alternative option was to capture these methods in a DOM-specific Woden API, like an API subset, but this suggests making some parts of the overall Woden API optional to implementors (i.e. to a StAX implementor) and this approach probably requires more thought and discussion.
      Hide
      John Kaputin added a comment -

      Resolved, pending feedback.

      Show
      John Kaputin added a comment - Resolved, pending feedback.
      Hide
      John Kaputin added a comment -

      Fixed in M5.

      Show
      John Kaputin added a comment - Fixed in M5.

        People

        • Assignee:
          John Kaputin
          Reporter:
          Guillaume Nodet
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development