RE: Problem with operation name in cpp doc lit

[Carsten Blecken]

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:[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]> 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