axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Blecken" <cblec...@macrovision.com>
Subject RE: Problem with operation name in cpp doc lit
Date Mon, 14 Feb 2005 23:48:38 GMT
Hi John,
 
I didn't want to imply that the fix was not well intended (quite the opposite), but looking
at my
 enviroment the fix to cpp/literal/ClientStubWriter.java 1.63 is a profound change.
 
I sync'd again reran the unit tests I have available (which is only a subset on what you have)
and have the tests AxisBench, ComplexTypeAll and FourLevelTestDoc fail.
 
Furthermore, the services we have (interoperating with an Axis java server) also don't work
any more.
 
I might have a problem in my env. but I can't see where.
 
Let's take the FourLevelTestDoc test as an example :
Without the fix we have the following envelope (from tcpm.req)
 
..
<SOAP-ENV:Body>
<ns1:FirstLevelElem xmlns:ns1="urn:org.apache:ws-axis/c/test/v1_0">
<ns1:SecondLevelElem><ns1:ThirdLevelElem><ns1:FourthLevelElem><ns1:SampleString>abc</ns1:SampleString>
<ns1:SampleInt>1</ns1:SampleInt>
</ns1:FourthLevelElem></ns1:ThirdLevelElem></ns1:SecondLevelElem></ns1:FirstLevelElem>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 
coming from the stub FourLevelTestDocInterface.cpp
 m_pCall->setOperation("FirstLevelElem", "urn:org.apache:ws-axis/c/test/v1_0");
 
with the fix we have
 
...
<SOAP-ENV:Body>
<ns1:RetrieveTestDoc xmlns:ns1="urn:org.apache:ws-axis/c/test/v1_0">
<ns1:SecondLevelElem><ns1:ThirdLevelElem><ns1:FourthLevelElem><ns1:SampleString>abc</ns1:SampleString>
<ns1:SampleInt>1</ns1:SampleInt>
</ns1:FourthLevelElem></ns1:ThirdLevelElem></ns1:SecondLevelElem></ns1:RetrieveTestDoc>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 
coming from the stub FourLevelTestDocInterface.cpp
 m_pCall->setOperation("RetrieveTestDoc", "urn:org.apache:ws-axis/c/test/v1_0");
 
Is this the same you have? Can you compare with your tcpm.req? The first env. adheres to the
schema defining
the cmplx type FirstLevelElem, the latter one doesn't.
 
The server throws an exception at the following statement in FourLevelTestDocInterfaceWrapper.cpp
 if (AXIS_SUCCESS != pIWSDZ->checkMessageBody("FirstLevelElem", "urn:org.apache:ws-axis/c/test/v1_0"))
return AXIS_FAIL;
which is quite obvious if the latter envelope is sent.
 
What am I missing?
 
Carsten
 
P.S> How about putting <service>#<operation> into the SOAP action?
 
 
 
 
 
 
 

-----Original Message-----
From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
Sent: Monday, February 14, 2005 4:55 AM
To: Apache AXIS C Developers List
Subject: Re: Problem with operation name in cpp doc lit



Hi Carsten, 

I'm confused. 

The fix was put in because otherwise the service is not called correctly. So, how come you're
saying that unit tests are failing? Is this not the case that the unit tests are wrong? 
When the fix is in, both the originating issue is fixed and the current doc/lit regression
tests all work. 

Can you help me see how this is bad ? 

thanks, 
John. 








"Carsten Blecken" <cblecken@macrovision.com> 


14/02/2005 05:09 


Please respond to
"Apache AXIS C Developers List"



To
<axis-c-dev@ws.apache.org> 

cc

Subject
Problem with operation name in cpp doc lit

	




Hi, 

there has been recently a change to the cpp doc lit code generator which sets the operation

name to the actual operation name (wsdl2ws/cpp/literal/ClientStubWriter.java). 


Problem with that is the operation name is being serialized, resulting in an 
incorrect doc lit wire representation so multiple unit tests are failing. The current implementation

is using for doc lit the root element of the wsdl part as operation name (probably 
due to RPC implemented first), but this should be just a workaround. 
I think it would be best to tackle this together with changing the Client API having 
to pass in the root element directly (an not having a dummy operation element in the 
xsd, i.e. a quasi 'wrapped' approach), but a change to the Client API is IMO not 
a good idea for 1.5 any more. 


So I wanted to roll back that change for now, file a JIRA bug  and in the 1.6 time frame we
can 
tackle this. 


Thanks, 


Carsten 





Mime
View raw message