[ 
https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amila Chinthaka Suriarachchi resolved AXIS2-2246.
-------------------------------------------------

    Resolution: Fixed

make part name unqualifed. so nonamespace associated with the part name.

> 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]

Reply via email to