[
https://issues.apache.org/jira/browse/AXIS2C-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimuthu Gamage updated AXIS2C-920:
----------------------------------
Attachment: case19.tar.gz
Hi Frank,
I think the problem1 you mentioned here is due to the bug you picked in
AXIS2C-921. I think that was the error and I did some fixes (commit 613361) and
was able to run my old test case after adding following entries to the schema..
(I think these are very similar to your schema)
<xs:element name="Categories" nillable="false"
minOccurs="0" maxOccurs="unbounded" type="xs:string" />
<xs:element name="newFine" type="xs:int"/>
<xs:element name="Query" nillable="false"
type="xs:string" />
<xs:element name="anotherFine" type="xs:int"/>
(Here fine, and newFine and anotherFine are just to separate the testing
elements)
Here are the expected behavior after this fix.
1. when minOccurs=0 for some for array element if the incomming xml doesn't
have the element, it just ignore it and continue to the next expected element..
(Fix of 921)
2. If the minOccurs != 0 ( and nillable) you should at least expect the element
once.
i.e.
for <xs:element name="Categories" nillable="true" minOccurs="1"
type="xs:string" />
the xml should have at lease one element of 'Catagories' like following.
<earlyElement></earlyElement>
<Catgories></Catagories>
<postElement></postElement>
and following is invalid
<earlyElement></earlyElement>
<postElement></postElement>
So although you said "array size of 0 for a type is not distinguishable from
an array type which was set to null", I think soap message of array size of 0
should be
<earlyElement></earlyElement>
<postElement></postElement>
and array type which was set to null should be
<earlyElement></earlyElement>
<Catgories></Catagories>
<postElement></postElement>
or more accurately,
<earlyElement></earlyElement>
<Catgories xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:nil="1"></Catagories>
<postElement></postElement>
Please correct me if I m wrong, if I m wrong this bug is in wsdl2c thing.
3. Whenever a type xs:string is set to null, we are expecting
<mystring xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:nil="1></mystring>
if somebody send <mystring/> or <mystring></mystring> then genereated code
thinks it is an empty string. This is because I can't have an idea which of
<mystring/>, <mystring></mystring> is there from axiom. (it always returns null
by axiom) .. :(. I m not sure this is a bug or not.
I added the test to nil attribute in the new fix. If you think this nil fix is
not necessary, I can change this to take it as an empty element, whenever found
empty element of string type,
- The below point is related to deserialization
4. If you want to send a empty string you have to explicitly set
adb_Lend_set_Query( _lend1, env, "");
otherwise serialization itself false..
NOTE: this is just the expected behavior and it worked with my test case (
There Axis2/C server inter ops with both Axis2/Java client and Axis2/C client).
Please check the attachment
> Array size of 0 for nillable variable in deserialization of SOAP messages
> -------------------------------------------------------------------------
>
> Key: AXIS2C-920
> URL: https://issues.apache.org/jira/browse/AXIS2C-920
> Project: Axis2-C
> Issue Type: Bug
> Components: wsdl2c tool
> Affects Versions: Current (Nightly)
> Reporter: Frank Huebbers
> Attachments: case19.tar.gz
>
>
> Hi,
> I am using Axis2/C in one of our applications to talk to our application
> server running Axis (java). I have run into problems where the return message
> isn't parsed because an array type of size zero with nillable=false is
> considered to be null by Axis2/C.
> In other words, I can give the following scenario:
> I want to send a SOAP message describing a book with an array list of
> authors. In my wsdl file, I have made the array type for the authors to be
> nillable=false as null types can generate problems for me on other systems. I
> still need to be able to send an empty array of authors however, to support
> special cases where no author is known for the book. So, when a SOAP message
> is received by my client which uses Axis2/C to deserialize it, I would expect
> Axis2/C to be able to recognize that an array of length zero was sent. What
> the generated code does instead, however, is that it thinks that the array
> type was set to null and thus throws an error. I would consider this to be
> incorrect behavior.
> When looking at the SOAP message, I have observed that an array size of 0 for
> a type is not distinguishable from an array type which was set to null and
> then sent. Specifically, the type is not shown in the message. Which is
> probably the root cause of this problem. What I have observed in these cases,
> however, is that C# and Axis Java are able to figure out that these array
> types are not null but arrays of size 0 (when they are defined as
> nillable=false in the wsdl files).
> Considering the facts above, I would thus suggest that the deserialization of
> the SOAP message for array types of size 0 follow a similar algorithm as is
> done in other implementations; otherwise, people will be forced to use
> different wsdl files for Axis2/C and other libraries.
> Any comments?
> Thanks for any help and advice in advance.
> Cheers,
> Frank
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
