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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
