Already done :-)
Nadir K. Amra
Nicholas Hart <[EMAIL PROTECTED]> 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 <[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]
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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]
