You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Nicholas Hart <nh...@real.com> on 2007/01/19 23:03:45 UTC
axiscpp parsing problem
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
Re: axiscpp parsing problem
Posted by Nadir Amra <am...@us.ibm.com>.
Already done :-)
Nadir K. Amra
Nicholas Hart <nh...@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 <nh...@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 <nh...@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
Re: axiscpp parsing problem
Posted by Nicholas Hart <nh...@real.com>.
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 <nh...@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 <nh...@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
Re: axiscpp parsing problem
Posted by Nadir Amra <am...@us.ibm.com>.
Could changed. See https://issues.apache.org/jira/browse/AXISCPP-830 for
resolution.
Nadir K. Amra
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: axiscpp parsing problem
Posted by Nadir Amra <am...@us.ibm.com>.
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 <nh...@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 <nh...@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
Re: axiscpp parsing problem
Posted by Nicholas Hart <nh...@real.com>.
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 <nh...@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
Re: axiscpp parsing problem
Posted by Nadir Amra <am...@us.ibm.com>.
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 <nh...@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