Axis2
  1. Axis2
  2. AXIS2-4451

Incorrect resolution of imported schema URLs

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Invalid
    • Affects Version/s: 1.4.1
    • Fix Version/s: 1.6.0
    • Component/s: wsdl
    • Labels:
      None

      Description

      [see the original email thread here: http://www.nabble.com/schema-location-resolution-td24648927.html]

      I have several services deployed under Axis2: S1, S1, S3. Each service packages it's own but identical to others copy of enterprise-common.xsd that gets imported from each service's specific schema file: [S1.wsdl <-- S1.xsd <-- enterprise-common.xsd; S3.wsdl <-- S3.xsd <-- enterprise.common.xsd].

      Let's say I next deploy a new service S4 which also has a copy of enterprise-common.xsd, but this copy is different from those included with other services (it has new element and type definitions).

      The location of S4's wsdl is <http://localhost/axis2/services/S4?wsdl>.

      When Axis2 serves the WSDL document, it rewrites schemaLocation to be 'schemaLocation="S4?xsd=S4.xsd"'. So, S4.xsd's absolute URL becomes
      <http://location/axis2/services/S4?xsd=S4.xsd>.

      enterprise-common.xsd location inside of S4.xsd is defined as 'schemaLocation="enterprise-common.xsd"'. When Axis2 returns S4.xsd
      it doesn't rewrite schema's location like it does with the wsdl document, so enterprise-common.xsd's absolute URL becomes
      <http://localhost/axis2/services/enterprise-common.xsd>.

      When Axis2 recieves a request for <http://localhost/axis2/services/enterprise-common.xsd>, which now doesn't have a service binding in the URL, as far as I can tell, it simply goes through all installed .aars looking for one that has the file. It finds it in the first service installed, say for example, S1. Unfortunately, S1 has the old version of enterprise-common.xsd that will against service S4.

      Also, consider these three URLs:

      1. http://localhost/axis2/services/enterprise-common.xsd
      2. http://localhost/axis2/services/S4/enterprise-common.xsd
      3. http://localhost/axis2/services/S4?xsd=enterprise-common.xsd

      Only #3 returns the schema that is defined inside of S4.aar (the newest version). #1 & #2 return an older version of enterprise-common.xsd that sits in other .aars. If I undeploy S1, S2, and S3 .aars, then #1 & #2 return the latest version from S4.

        Activity

        Hide
        Senaka Fernando added a comment - - edited

        #1 and #2 no longer returns a wrong schema. It returns a soap fault.

        Thanks,
        Senaka.

        Show
        Senaka Fernando added a comment - - edited #1 and #2 no longer returns a wrong schema. It returns a soap fault. Thanks, Senaka.
        Hide
        Warren Janssens added a comment -

        I'm having the exact same problem – only the first level of xsd files is having the schemaLocation rewritten. Having multiple xsd files is a perfectly legitimate use case so I'm not sure I'm not sure why this is marked as invalid. What other strategies are there for serving large hierarchies of xsd files?

        Show
        Warren Janssens added a comment - I'm having the exact same problem – only the first level of xsd files is having the schemaLocation rewritten. Having multiple xsd files is a perfectly legitimate use case so I'm not sure I'm not sure why this is marked as invalid. What other strategies are there for serving large hierarchies of xsd files?
        Hide
        Paul Thevenot added a comment -

        Got the same problem today with the 1.3 version. After upgrade to the 1.6.2 version, it's working well!

        Show
        Paul Thevenot added a comment - Got the same problem today with the 1.3 version. After upgrade to the 1.6.2 version, it's working well!

          People

          • Assignee:
            Senaka Fernando
            Reporter:
            dmitry beransky
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development