axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Chinthaka Suriarachchi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb codegen create messages that are non WS-I complient
Date Thu, 05 Apr 2007 05:16:32 GMT

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

Amila Chinthaka Suriarachchi commented on AXIS2-2246:
-----------------------------------------------------

in your wsdl file you have made the namesapce of the soap:body element and the targetnamsapce
of your schema equal. 
When processing the wsdl document, Axis2 creates a new Element for each Operation (in RPC
style) in the soap:body namespace. But your xsd already have an element with the same name
in this namespace. Then Axis2 has pick your original (i.e. in the xsd) element when setting
the Element Qname references.
Is this senario valid? 
The spec says the wrapping element should be in the soap:body namespace  and its' local name
should be operation name. This means it defines an element with the above namesapce and the
localpart. (I think this is the reason why it has sudjested to append 'Response' sufix when
creating the response message to make it unique). So is it valid to have another element is
that same namespace with the same local name? (for top level elements Qname must be unique)
 

> 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


Mime
View raw message