axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From axis-...@ws.apache.org
Subject [jira] Commented: (AXIS-1437) Wrong behavior on <xsd:choice>
Date Fri, 08 Oct 2004 05:39:52 GMT
The following comment has been added to this issue:

     Author: Matthias Germann
    Created: Thu, 7 Oct 2004 10:37 PM
       Body:
I'm having the same problem with AXIS 1.2 RC1.
---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/AXIS-1437?page=comments#action_53825

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1437

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1437
    Summary: Wrong behavior on <xsd:choice>
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis
 Components: 
             Serialization/Deserialization
   Versions:
             1.1

   Assignee: 
   Reporter: easyproglife

    Created: Wed, 7 Jul 2004 1:39 AM
    Updated: Thu, 7 Oct 2004 10:37 PM
Environment: Win2000/PC/JDK1.4

Description:
I see Axis client wrong behavior on serializing a message built from schema with xsd:choice.

I have XML schema with <xsd:choice>:

<xsd:complexType name="getSubscriberRequest">
  <xsd:choice minOccurs="0">
    <xsd:element name="customerID" type="cc:customer"/>
    <xsd:element name="phoneNumber" type="cc:serviceDetails"/>
    <xsd:element name="status" type="cc:serviceStatusEnum"/>
    <xsd:element name="phoneType" type="cc:phoneTypeEnum"/>
  </xsd:choice>
</xsd:complexType>

(The business logic idea is to request some data according to one and only one parameter (i.e.
status, phoneNumber, etc.)).

In the client code, I do the following:

GetSubscriberRequest req = new GetSubscriberRequest();		
req.setPhoneNumber(new ServiceDetails("9412345678"));		
GetSubscriberResponse res = stub.getSubscriber(req);

The XML message over the wire is:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <getSubscriberRequest xmlns="http://www.xxx.com/yyy">
   <customerID xsi:nil="true"/>
   <phoneNumber>941234567</phoneNumber>
   <status xsi:nil="true"/>
   <phoneType xsi:nil="true"/>
  </getSubscriberRequest>
 </soapenv:Body>
</soapenv:Envelope>

I am using Castor at the server side, and it fails on validation:

ValidationException: The element 'phoneNumber' cannot exist at the same time that element
'customerID' also exists.;
   - location of error: XPATH: getSubscriberRequest

Castor behavior seems ok to me, since xsd:choice by definition should allow ONLY ONE ELEMENT
of its subelements.

The wrong behavior, for my opinion, is in Axis. It produces elements with xsi:nil="true" (in
xsd:choice) instead of not generating them at all.

Looking at the source code, I see that org.apache.axis.encoding.SerializationContext.serialize()
(line 115) get 6 parameters. The one before the last one is "sendNull". If it is false, the
Axis behavior would be perfect for my situation!

The problem is the all the built-it serializers (i.e. BeanSerializer, line 238) sends hard-coded
"true" for this parameter, hence force Axis to generate an empty element with xsi:nil="true",
that is invalid and cause Castor validation to fail.

For my opinion, there should be a configurable parameter the controls the behavior of "sendNull"
parameter in SerializationContext. 

I think that on xsd:choice, the default behavior must be to ommit the null elements at all!



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message