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]
