[
https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486829
]
Tim Buss commented on AXIS2-2246:
---------------------------------
I have finally narrowed down the mysterious issue with the more complex schema
and rpc-literal. It is a fairly bizarre bug.
If you have a service the is rpc-literal for which you declare a message (eg:
"NewOperation") which has a part with the same name (ie "NewOperation") eg:
<wsdl:message name="NewOperation">
<wsdl:part name="NewOperation" type="xsd:string" />
</wsdl:message>
and then you include a schema file in the wsdl:types section of the WSDL
<xsd:include schemaLocation="Axis2RPCLiteralTest.xsd"/>
that declares a top level element that has the same name as the operation and
part (ie "NewOperation" )
<xsd:element name="NewOperation" type="xsd:string"/>
Then the generated client code will send Document Literal style messages
instead of RPC Literal style messages and the generated server will accept them
and respond, strangely, with an RPC-Literal style message.
Removing the element declaration avoids the issue and the correct RPC-literal
messages are exchanged.
I am using the Axis 1.1.1 SNAPSHOT from 3/21/07 withthe axiom snapshot from
3/23/07
I am generating the service with the following command:
%AXIS2_HOME%/bin/wsdl2java.bat -uri wsdl/Axis2RPCLiteralTest.wsdl -p
org.example.www.axis2rpcliteraltest -s -ss -sd -g -u -t
Now I can reproduce it I will get the latest snapshots and see if it still
shows up.
> Rpc-Literal Client and Server adb codegen create messages that are non WS-I
> complient
> --------------------------------------------------------------------------------------
>
> Key: AXIS2-2246
> URL: https://issues.apache.org/jira/browse/AXIS2-2246
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb
> Affects Versions: 1.1.1
> Environment: Axis 1.5, Tomcat 5.5, Axis2 1.1.1, Axis2 Eclipse codegen
> plugin 1.1.1, Eclipse 3.2, WTP 1.5.1, Windows 2003 server
> Reporter: Tim Buss
> Priority: Critical
> Attachments: Axis2RPCLiteralTest.wsdl
>
>
> 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 . 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. In
> particualr WS-I Basic 1.0 states:
> "4.7.20 Part Accessors
> For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any, the
> accessor elements for parameters and return value are a part of. Different
> implementations make different choices, leading to interoperability problems.
> R2735 An ENVELOPE described with an rpc-literal binding MUST place the part
> accessor elements for parameters and return value in no namespace.
> R2755 The part accessor elements in a MESSAGE described with an rpc-literal
> binding MUST have a local name of the same value as the name attribute of the
> corresponding wsdl:part element.
> Settling on one alternative is crucial to achieving interoperability. The
> Profile places the part accessor elements in no namespace as doing so is
> simple, covers all cases, and does not lead to logical inconsistency. "
> http://www.ws-i.org/Profiles/BasicProfile-1.2.html
> 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>
> One other difference that may be a factor in this case is that my complex
> service is one way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
