On 2/22/07, tgb <[EMAIL PROTECTED]> wrote:
There appears to be two problems. The most obvious is that the
RPC-literal
message sent by the generated client and accepted by the generated service
is incorrect - or so I believe. The following message body is sent for
the
various test cases I have tried - string, complex type, nested complex
type.
<soapenv:Body>
<ns:OperationName>
<ns:PartName>
.............content.....
</ns:PartName>
</ns:OperationName>
</soapenv:Body>
but it should be:
<soapenv:Body>
<ns:OperationName>
<PartName>
.............content.....
</PartName>
</ns:OperationName>
</soapenv:Body>
PartName should be a non qualified name. Axis 1.3 did it this way, and
other sources support this as being the correct form for rpc-literal.
What are those other sources? I check with the WSDL spec and basic profile
but could not find a clue to confirm this. So If you have found any thing
please let us know. Do you have any experience with .Net and other
soapstacks?
if every one does it with out using the namespace we can do the same to
axis2.
The second problem that I have yet to narrow down is that with a much more
complex type, the generated client sends a message with a body like this
where the "part" element is not present:
<soapenv:Body>
<ns:OperationName>
.............content.....
</ns:OperationName>
</soapenv:Body>
I tested this with the current trunk. Here is the request
<ns1:NestedOperation xmlns:ns1="http://www.example.org/Axis2RPCLiteralTest/
">
<ns1:NestedOperationRequest>
<ns1:Nested>
<ns1:Field1>string 1</ns1:Field1>
</ns1:Nested>
</ns1:NestedOperationRequest>
</ns1:NestedOperation>
Can you please test this with a nightly build? but I think this should work
correctly with the axis2 1.1.1 as well.
Thanks,
Tim
--
Amila Suriarachchi,
WSO2 Inc.
