axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Hart <>
Subject Re: axiscpp parsing problem
Date Fri, 19 Jan 2007 23:20:51 GMT
that looks like the exact problem I'm seeing.  for the heck of it I 
tried removing enforcement of the type checking in getElement() and it 
seems to progress farther.  the problem I'm encountering now is that the 
order of elements returned doesn't match the order in which the 
generated stub tries to parse them--which is causing a different failure.

I can probably work around that by tweaking my stub code.

this is ugly, but here's the change I made to allow parsing to continue 
if the node contains no type attribute (I'm not proposing this as a 
change--it needs to be cleaned up so we don't call getXSDType twice on 
the same node).

Index: soap/SoapDeSerializer.cpp
--- soap/SoapDeSerializer.cpp	(revision 497694)
+++ soap/SoapDeSerializer.cpp	(working copy)
@@ -1369,7 +1369,7 @@
          if (0 == strcmp (pName, m_pNode->m_pchNameOrValue))
              bNillFound = isNillValue();

-        if (bNillFound || isArrayElement || (pSimpleType->getType() == 
getXSDType (m_pNode)))
+        if (bNillFound || isArrayElement || (pSimpleType->getType() == 
getXSDType (m_pNode)) || (getXSDType (m_pNode) == XSD_UNKNOWN))
              m_pNode = m_pParser->next (true);   /* charactor node */
              if (!m_pNode)

Nadir Amra wrote:
> Nicholas,
> I too am not sure if a type is required.  I need to do some investigation. 
>  I know there is AXISCPP-830  that is related.  I will investigate, but if 
> someone can look into this and let us know then a fix can be expedited. 
> And if you can attach a sample wsdl and SOAP response, it will expedite a 
> fix. 
> Nadir K. Amra
> Nicholas Hart <> wrote on 01/19/2007 04:03:45 PM:
>>I'm not having much luck with an axis2c client, so I've returned to 
>>axiscpp--which I almost seem to have working.  I've built a debug 
>>version from svn and I've verified that I receive a response from my 
>>server (I can see it in ethereal and in 
>>SoapBinInputStream::readBytes()), but when trying to parse the response, 
>>SoapDeSerializer::getElementAsString() is failing.
>>in my generated client stub, the call to "m_pCall->checkMessage()" 
>>succeeds, so it does seem to receive the correct message in the 
>>response.  however, m_pCall->getCmplxObject() fails, returning NULL. 
>>Stepping into getCmplxObject() I see that when it tries to parse the 
>>very first element (via pIWSDZ->getElementAsString()) it fails.
>>the element it is trying to parse looks something like this:
>><foo>some text here</foo>
>>I would expect that it should return "some text here" but instead, it 
>>fails.  I believe this is because inside SoapDeSerializer::getElement(), 
>>it calls SoapDeSerializer::getXSDType() on the element (in this case, 
>>"foo") and it fails, because the element has no attributes.  XSD_UNKNOWN 
>>is returned, and since it doesn't match XSD_STRING, getElement() fails. 
>>  of course, the rest of the parsing fails since the status is set to an 
>>since I'm not too familiar with how this is supposed to work I am 
> wondering:
>>1. is the server response bad (ie: should it be providing some 
>>attributes on that node?)
>>2. is the client configured incorrectly (ie: should it be able to parse 
>>this, with the right settings somewhere?)
>>3. is this a bug in the client that I should try to fix?
>>thank you!
>>PS: let me know if this should go on the dev list instead.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message