AXIS 1.1 Fails to Serialize and Deserialize XML Attributes

[Tony Opatha <to...@yahoo.com>]

Hi Glen:
 
There is a critical problem getting attribute defined in the base complex type to be serialized (or de-serialized) by AXIS 1.1 This test-case passes in gSOAP and
.NET 1.1/VS.NET 2003/WSE 2.0. I believe in November there was a patch for
this that you made available that could work for AXIS 1.1. 
 
Can you please send me that patch and/or let the list know where it is available?
 

Included below is the schema fragment that describes the structure of the XML payload:

// child type
<xs:complexType name="AType">
<xs:complexContent>
<xs:extension base="ns2:AbstractAType">
<xs:sequence>
<xs:element ref="ns2:id"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

// The base complexType that contains an attribute and an element
<xs:complexType name="AbstractAType" abstract="true">
<xs:attribute name="a" type="xs:string" use="optional"/>
<xs:element name="e" type="ns:BType">
...
</xs:complexType>


When WSDL2Java is used to generate the stub for the client, it was able to generate the 2 java files properly . In the client application that uses the AXIS 1.1 generated client stub, the attribute value (in AbstractAType) is explicitly the set and the element of object AType is also set. 
 
However, in the SOAP message that gets sent over the wire, the attribute a is always getting dropped. The element e though, is serialized properly.
 
Reviewing the actual generated AType.java and AbstractAType.java, one behavior that
is observed is that .the typeDesc private member in AType doesn't know about the TypeDesc private member in AbstractAType, and doesn't references it.

So when calling the BeanSerializer and passing in that typeDesc, it only contains the AType type desc information, but not the parent's  (AbstractAType) one (in this case, that contains the element and attribute). 

So how come somehow the element was still able to be retrieved and serialized not the attribute?

It seems that the root problem may be the way AXIS is generating the stubs and skeletons. If in the generated code add the parent class's attr field to the typedesc of the extended class: 

       typeDesc.addFieldDesc(attrField); 

or something like that it may be fix the problem of serializing the required XML Attributes

that are inherited from the base complexType.

Since this is a major show-stopper in terms of not being able to serialize XML attributes

within document-style (Doc/Lit) style SOAP messages, please suggest workaround

and/or confirm if there are plans to fix this in AXIS 1.2.

 

Thank you very much for all your help.


 



---------------------------------
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing