Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-4910

Bad handling of Schema imports (WSDLGetInterceptor)

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.7.3
    • 2.7.11, 2.6.14, 3.0
    • Simple Frontend
    • None
    • Windows

    • Unknown

    Description

      While doing my experiments with completely dynamic service creation from WSDL only, I found suspicious code in WSDLGetInterceptor regarding schema cacheing.
      A following example results in incorrect behavior:

      Namely:
      WSDLGetUtils.updateSchemaImports() uses a map for caching processed schemata.
      A service built from following path layout

      Wsdl.wsdl
      z/Types.xsd
      z/z/Types.xsd
      

      Where

      results in incorrect serving of service definition when querying the endpoint.

      The link from wsdl to import points to "?xsd=z/Types.xsd".

      <wsdl:definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://example.com/Service/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" name="Service" targetNamespace="http://example.com/Service/">
      <wsdl:types>
      <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://example.com/Service/" xmlns:sty="http://example.com/StructTypes" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace="http://example.com/Service/">
      <xsd:import namespace="http://example.com/StructTypes" schemaLocation="http://localhost:8080/Service?xsd=z/Types.xsd"/>
      [...SNIP...]
      

      The link from z/Types.xsd points again to itself "?xsd=z/Types.xsd" (same content is served).

      <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://example.com/StructTypes" xmlns:bty="http://example.com/BaseTypes" targetNamespace="http://example.com/StructTypes">
      <xsd:import namespace="http://example.com/BaseTypes" schemaLocation="http://localhost:8080/Service?xsd=z/Types.xsd"/>
      [...SNIP...]
      

      This is because the WSDLGetUtils cuts of the schemata processing on the first import because relative path is used as key identifier in the schema map.

      I suspect the same applies for the WSDL imports in WSDLGetUtils.updateDefinition() due to caching the definitions in the definition map.

      Attachments

        Issue Links

          Activity

            People

              ema Jim Ma
              erce Rastislav Cesnek
              Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: