Axis
  1. Axis
  2. AXIS-2578

Incorrect namespace for xsi:type value causes problems with non-Axis clients

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Java 1.5.0_07-b03
      Axis 1.4
      Castor 0.9.5.3 or Castor 1.0.3

      Description

      I have a Document/Literal web service implemented with Axis 1.4 using Castor 0.9.5.3 - also tried Castor 1.0.3 - for serialization of XML. The WSDL includes XML schema objects from several namespaces, and uses XML inheritance which causes xsi:type attributes to be used. When a non-Axis client - I have tried .NET and Python - try to use my web service they cannot resolve the correct type for an element that has an xsi:type that defines its actual type. I believe the XML returned by Axis is incorrect, the xsi:type value does not have a namespace prefix, but the default namespace has a different URI than what the value of the xsi:type should use.

      In this example, Bug, BugSpecifier, and EnhancementRequest are defined in the http://example.com/bug namespace, however the XML returned by Axis does not use the ns1 prefix in the value of the xsi:type attribute that defines the Bug as an EnhancementRequest. Axis clients appear to ignore this issue, however .NET and Python cannot resovle EnhancementRequest in the http://example.org/bug/remote namespace.

      <getBugResponse xmlns="http://example.org/bug/remote">
      <ns1:BugSpecifier xmlns:ns1="http://example.org/bug">
      <ns1:Bug xsi:type="EnhancementRequest">

      The attachment bug.zip contains an example project that reproduces this problem. The org.example.bug.client.BugClient class calls this web service, however since it is an Axis client it does not have a problem with the incorrect namespace; a .NET, Python, or other web service client that respects the namespace in the xsi:type will have a problem with this web service.

      I believe this issue can be solved by adding the method startPrefixMapping to org.apache.axis.encoding.ser.castor.AxisContentHandler, and route the call to context.registerPrefixForURI(prefix, uri), i.e.

      public class AxisContentHandler extends DefaultHandler {
      /**

      • notifies the serialization context of the new namespace mapping
        */
        public void startPrefixMapping(String prefix, String uri)
        throws SAXException { context.registerPrefixForURI(prefix, uri); }

      This makes the Axis SerializationContext aware of the namespaces that Castor is using. I have tried this fix with Castor 0.9.5.3 and 1.0.3 and it generates the correct namespaces.

      1. bug.zip
        3.86 MB
        Michael McRoberts
      2. fix.zip
        0.4 kB
        Michael McRoberts

        Activity

        Hide
        Michael McRoberts added a comment -

        Proposed fix, propogate Castor namespaces to the SerializationContext in org.apache.axis.encoding.ser.castor.AxisContentHandler

        Show
        Michael McRoberts added a comment - Proposed fix, propogate Castor namespaces to the SerializationContext in org.apache.axis.encoding.ser.castor.AxisContentHandler
        Hide
        Michael McRoberts added a comment -

        An example project that reproduces the bug issue.

        Show
        Michael McRoberts added a comment - An example project that reproduces the bug issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael McRoberts
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development