You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Tim Buss (JIRA)" <ji...@apache.org> on 2007/04/05 03:37:32 UTC
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org