|
I am using Axis 1.1 (not the CVS version
with castor serialization) and doing the castor serialization on the server
side by hand. Given the following wsdl with an xsd:choice group (this is just an academic example to show the
problem)
...
<xsd:schema ..."> <xsd:complexType name="MyChoice"> <xsd:choice>
<xsd:element name="shirt"
type="xsd:string"/>
<xsd:element name="hat"
type="xsd:string"/>
<xsd:element name="umbrella"
type="xsd:string"/>
</xsd:choice> </xsd:complexType> <xsd:element name="requestChoice"
type="MyChoice"/> <xsd:element name="responseChoice"
type="MyChoice"/>
</xsd:schema> </wsdl:types> <wsdl:message
name="showChoiceResponse"> <wsdl:part
element="impl:responseChoice" name="body"/> </wsdl:message> <wsdl:message
name="showChoiceRequest"> <wsdl:part
element="impl:requestChoice" name="body"/> </wsdl:message>
... .... An axis client using WSDL2Java on the above wsdl sends
the following SOAP message: ... <soapenv:Body>
<requestChoice xmlns="http://schema.mbi.com">
<shirt>its a shirt</shirt>
<hat xsi:nil="true"/>
<umbrella xsi:nil="true"/>
</requestChoice> </soapenv:Body> ... On the server side the castor unmarshalling throws
this exception ValidationException: The element 'hat' cannot exist at
the same time that element 'shirt' also exists.; -
location of error: XPATH:
requestChoice Based on the definition of an xsd:choice
group, it seems like castor is doing the right thing on the server side and
axis is doing the wrong thing on the client side. Why does axis serialization Is there a way to stop the xsi:nil
elements from being added to the soap message on the axis side? With the axis cvs release will the castor
serialization behave any differently? With the axis cvs release will the axis client side
behave any differently? Thanks Keith |
- RE: xsd choice problem using castor serialization on ... Keith Bohnenberger
- RE: xsd choice problem using castor serializatio... Sapozhnikov, Michael
