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

• Key: AXIS-2578
• Type: Bug
• Status: Open
• Priority: Major
• Assignee: Unassigned
• Reporter: Michael McRoberts
• Component/s: Serialization/Deserialization
• Affects Version/s: 1.4

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.

Comments

[Michael McRoberts]

An example project that reproduces the bug issue.

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