You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Frank Huebbers (JIRA)" <ji...@apache.org> on 2008/01/19 00:35:34 UTC
[jira] Created: (AXIS2C-920) Array size of 0 for nillable variable
in deserialization of SOAP messages
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
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-920) Array size of 0 for nillable
variable in deserialization of SOAP messages
Posted by "Frank Huebbers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560608#action_12560608 ]
Frank Huebbers commented on AXIS2C-920:
---------------------------------------
Btw, I defined the element as follows in the wsdl file:
<element name="Categories" nillable="false" minOccurs="0" maxOccurs="unbounded" type="Author" />
Frank
> 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
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXIS2C-920) Array size of 0 for nillable variable
in deserialization of SOAP messages
Posted by "Dimuthu Gamage (JIRA)" <ji...@apache.org>.
[ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-920) Array size of 0 for nillable
variable in deserialization of SOAP messages
Posted by "Frank Huebbers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560630#action_12560630 ]
Frank Huebbers commented on AXIS2C-920:
---------------------------------------
I have actually found an even more important shortcoming which I can illustrate with the following example.
I have a wsdl file with the following type:
<complexType name="SearchQuery">
<sequence>
<element name="Query" nillable="false"
type="xsd:string" />
<element name="Offset" nillable="false"
type="xsd:int" />
<element name="Limit" nillable="false"
type="xsd:int" />
</sequence>
</complexType>
On the return, I receive the following response:
<SearchQuery>
<Query/>
<Offset>0</Offset>
<Limit>10</Limit>
</SearchQuery>
Note that in this case, I sent an empty string for the query. In the deserialization of the type, however, Axis2/C considered the returned type to be null, causing a failure in the parsing of the object since the object is set to nillable=false.
Frank
> 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
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-920) Array size of 0 for nillable
variable in deserialization of SOAP messages
Posted by "Frank Huebbers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560862#action_12560862 ]
Frank Huebbers commented on AXIS2C-920:
---------------------------------------
Hi Dimuthu,
Please see my comments below for the points you made above:
1. Sounds good
2. Sounds good
3. I am not sure whether this was fixed as well with your bugfix for 921, however, I have observed that I get a deserialization error when I receive an empty string on a type which is not nillable (i.e., nillable=false).
As I had mentioned in my post, the message contained <myString/> which, as you have stated, should be interpreted as an empty string. This did not work for me. Only when I received a string with a value, i.e., <myString>hello</myString> did the deserialization of the string work correctly.
Othwerise, what you are expecting when a type of xs:string is set to null makes sense. Note that this is not the use case I am describing though.
4. Makes sense.
Thanks for the create feedback.
I will try out your new fix ones the problem I have described in Bug 863 has been fixed. It sounds like you haven't been able to reproduce that issue on your end. So, I'll try to dig a little deeper there myself when I have some more time and then let you know what I find.
Thanks Dimuthu.
Cheers,
Frank
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Closed: (AXIS2C-920) Array size of 0 for nillable variable
in deserialization of SOAP messages
Posted by "Frank Huebbers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Huebbers closed AXIS2C-920.
---------------------------------
Resolution: Fixed
Fix Version/s: Current (Nightly)
All of the issues raised here were fixed and I was able to verify this with the snapshot from 7/2/2008.
> 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
> Fix For: Current (Nightly)
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org