[ 
https://issues.apache.org/jira/browse/AXISCPP-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nadir amra closed AXISCPP-1022.
-------------------------------

       Resolution: Cannot Reproduce
    Fix Version/s: current (nightly)

Please download and build latest code from SVN.  I believe that problem is 
fixed.

> Bug preventing SoapDeSerializer::deserializeEncodedArray() from working
> -----------------------------------------------------------------------
>
>                 Key: AXISCPP-1022
>                 URL: https://issues.apache.org/jira/browse/AXISCPP-1022
>             Project: Axis-C++
>          Issue Type: Bug
>          Components: Client - API
>    Affects Versions:  1.6 Beta,  1.6 Final
>         Environment: Windows XP
>            Reporter: Javier Cámara
>             Fix For: current (nightly)
>
>
> There is a bug in SoapDeSerializer::deserializeEncodedArray which prevents it 
> from decoding any correctly SOAP-encoded array . The original source contains 
> the following loop for traversing array elements:
> >>>>>>>>>>>>>>>>
>     for (int count = 0 ; count < size; count++)
>     {
>         const char* elementName = peekNextElementName();
>         if(strcmp(elementName, pName) != 0)
>         {
>             getElement(pName, pNamespace, pSimpleType, true);
>             void * pValue = pSimpleType->getValue();
>             pArray->addElement(pValue);
> <<<<<<<<<<<<<<<<
> If the "if" is true then the read element is added to the array. If it is 
> not, then the loop exits and ends up with an empty array. Thus, the condition 
> of the "if" is reversed; it should be:
>         if(strcmp(elementName, pName) == 0)
> In the original form, it just does not work and renders the client unable to 
> read any returned array.
> I have tested the fix with version 1.6b (March 2006) and seems to work. I 
> guess version 1.6 (August 2006) is also affected since it shows the same 
> behavior. However I have not found sources for such 1.6 and thus I cannot be 
> sure.
> A workaround would be not to use RPC/encoded but RPC/literal or 
> document/literal, moreover when of course RPC/encoded is discouraged by WS-I. 
> But the fact is that not every web service developer knows or cares about 
> this.
> Regards

-- 
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]

Reply via email to