axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nadir Amra <a...@us.ibm.com>
Subject Re: axiscpp parsing problem
Date Mon, 22 Jan 2007 19:15:55 GMT
Already done :-)

Nadir K. Amra


Nicholas Hart <nhart@real.com> wrote on 01/22/2007 12:59:07 PM:

> I'll clean up the change and attach it to the issue in jira, so we can 
> use the established processes.
> 
> Nadir Amra wrote:
> > I guess I do not have any problem putting in the change to allow 
UNKNOWN 
> > type to be passed in.  Will a few days to see if there are any 
objections.
> > 
> > Nadir K. Amra
> > 
> > 
> > Nicholas Hart <nhart@real.com> wrote on 01/19/2007 05:20:51 PM:
> > 
> > 
> >>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 <nhart@real.com> 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 
> > 
> >>>
> >>>>error...
> >>>>
> >>>>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: axis-c-user-unsubscribe@ws.apache.org
> >>>>For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> >>>For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> >>For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >>
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > 
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org


Mime
View raw message