I
suppose we could add a method
void AXISCALL setPartRootElement(const char*
pchName,
const char* pchNamespace);
const char* pchNamespace);
to the
Call object which would then get the root level element
and
the soapmethod would then serialize that (and not the
operation name).Not my favorite option,
since this method
is
just introduced for fixing this and should be obsoleted by
the
final solution, but this should also work and would
acceptable.
This
leaves us with three option
1)
rollback change
2) add
setPartRootElement
3)
change the Client API as in the thread below indicated. This
would be the right way, but would be a
larger change and
could impact the beta/final schedule.
Other
opinions?
Carsten
-----Original Message-----
From: John Hawkins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 16, 2005 2:09 AM
To: Apache AXIS C Developers List
Subject: RE: Problem with operation name in cpp doc lit
I think I'd prefer to just replace or add another method instead of setOperation - as this is not what it does at all .
"Carsten Blecken" <[EMAIL PROTECTED]> 15/02/2005 19:19
"Apache AXIS C Developers List"
"Apache AXIS C Developers List" <[email protected]> RE: Problem with operation name in cpp doc lit
Hi John,
I'm glad to see that you guys are coming around :)
The reason why some unit test succeed is that the operation name is
equal to the root level element, which is not the case in general.
In case they are not equal I have a hard time understanding why the
unit tests would work.
Yes I'm getting AxsiBench.wsdl from ws-axis/c/tests/auto_build/testcases/wsdls.
I made one change locally by setting soapAction="AxisBench#doBenchRequest"
So I'll be rolling back the change to ClientStubWriter.java (I don't see a better way
for now) and file a new ticket we can address in 1.6.
My idea would be to change the stub from
SecondLevelElemType_Array FourLevelTestDocInterface::RetrieveTestDoc(SecondLevelElemType_Array Value0)
{
SecondLevelElemType_Array RetArray = {NULL, 0};
const char* pcCmplxFaultName;
try
{ if (AXIS_SUCCESS != m_pCall->initialize(CPP_DOC_PROVIDER)) return RetArray;
m_pCall->setTransportProperty(SOAPACTION_HEADER , "FourLevelTestDocService#RetrieveTestDoc");
m_pCall->setSOAPVersion(SOAP_VER_1_1);
m_pCall->setOperation("FirstLevelElem", "urn:org.apache:ws-axis/c/test/v1_0");
includeSecure();
applyUserPreferences();
char cPrefixAndParamName0[25];
sprintf( cPrefixAndParamName0, "%s:SecondLevelElem", getNamespacePrefix("urn:org.apache:ws-axis/c/test/v1_0"));
m_pCall->addCmplxArrayParameter((Axis_Array*)(&Value0), (void*)Axis_Serialize_SecondLevelElemType, (void*)Axis_Delete_SecondLevelElemType, (void*) Axis_GetSize_SecondLevelElemType, "SecondLevelElem", Axis_URI_SecondLevelElemType);
to
FirstLevelElemType FourLevelTestDocInterface::RetrieveTestDoc(FirstLevelElemType Value0)
{
FirstLevelElemType_Array RetArray = {NULL, 0};
const char* pcCmplxFaultName;
try
{ if (AXIS_SUCCESS != m_pCall->initialize(CPP_DOC_PROVIDER)) return RetArray;
m_pCall->setTransportProperty(SOAPACTION_HEADER , "FourLevelTestDocService#RetrieveTestDoc");
m_pCall->setSOAPVersion(SOAP_VER_1_1);
m_pCall->setOperation("RetrieveTestDoc", "urn:org.apache:ws-axis/c/test/v1_0");
includeSecure();
applyUserPreferences();
m_pCall->addCmplxParameter(Value0, (void*)Axis_Serialize_FirstLevelElemType, (void*)Axis_Delete_FirstLevelElemType, (void*) Axis_GetSize_FirstLevelElemType, "FirstLevelElem", Axis_URI_FirstLevelElemType);
This would require SoapMethod.cpp to be sensitive to RPC vs. doc lit and in the latter case not to serialize the
operation name. Note that this changes the client interface and requires several of the unit tests to be retrofitted.
Thanks,
Carsten
-----Original Message-----
From: John Hawkins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 15, 2005 1:55 AM
To: Apache AXIS C Developers List
Subject: RE: Problem with operation name in cpp doc lit
Hi Carsten,
You're absolutely right !
I agree completely :-)
I just realised the reason why this comes around is because our WSDL's are terribly written and have the same names everywhere ! Not quite sure how come your tests fail when ours don't however - are you getting the AxisBench.wsdl from ws-axis/c/tests/auto_build/testcases/wsdls?
We've changed WSDL2Ws accordingly - thanks for helping us understand !
cheers,
John.
"Carsten Blecken" <[EMAIL PROTECTED]> 14/02/2005 23:48
"Apache AXIS C Developers List"
"Apache AXIS C Developers List" <[email protected]> RE: Problem with operation name in cpp doc lit
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
"Apache AXIS C Developers List"
<[email protected]> 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
