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/02/23 08:06:05 UTC
[jira] Created: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
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
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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483089 ]
Amila Chinthaka Suriarachchi commented on AXIS2-2246:
-----------------------------------------------------
The reason for your problem should be an incompatibility of Axiom versions. there was a change to axiom builder at that time and may be related to that. Please have a look at with a latest build.
Can you send the wsdl which you do not get the correct request message? What do you mean by *document literal style messages*?
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483397 ]
Amila Chinthaka Suriarachchi commented on AXIS2-2246:
-----------------------------------------------------
you have to use the axiom-SNAPSHOTs. I think dims currently working on correcting the build break. Actually correct axiom jars should be delivered with the build i think.
'I would prefer to give you a more focused example' that would be much better, please send it soon so that I can fix it before Axis2 1.2
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486888 ]
Tim Buss commented on AXIS2-2246:
---------------------------------
I assume you are referring to this paragraph of the WS-I basic profile.
"Conversely, in a rpc-literal SOAP binding, the serialized child element of the soap:Body element consists of a wrapper element, whose namespace is the value of the namespace attribute of the soapbind:body element and whose local name is either the name of the operation or the name of the operation suffixed with "Response". The namespace attribute is required, as opposed to being optional, to ensure that the children of the soap:Body element are namespace-qualified."
It would be normal to declare the element in the document literal case since the document literal message would reference the element as its "document" type. I see no reason why such an element would be illegal in the RPC-literal case since no such element actually exists elsewhere in the same namespace in the schema or WSDL. The fact that the WSDL implies the generation of such an element in the SOAP message is independent of the schema even if it might logically create a conflicting definition. In the rpc literal case the wrapper element of an rpc-literal soap message is not technically part of a document defined by the schema and can't be validated by it. I understand your point but this worked in Axis 1.X and passes the WS-I check in WTP so I suspect it is legal even if it is logically suspect.
In any case, whether this is illegal or legal and a restriction of Axis2 it should not generate code that apparently works but does the wrong thing! At the very least it should generate a warning or an error. Possibly pre-scanning for WS-I compliance such as is done by the eclipse WTP tool would be the only easy way to do this. However, since it is known from the WSDL that the service is rpc-literal and the WSDL defines what namespace and name the wrapper element should have as described above, it seems reasonable to ignore any other definitions conflicting or otherwise and just generate code that does the right thing.
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483398 ]
Amila Chinthaka Suriarachchi commented on AXIS2-2246:
-----------------------------------------------------
As a temporaliy solution, you can deploy the SNAPSHOT generated axis2 service (i.e. aar) file in Axis2 1.1.1 server.
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485584 ]
Tim Buss commented on AXIS2-2246:
---------------------------------
I should point out that I used the wsdl2java command line tool for the SNAPSHOT tests. I tried the eclipse plugin since I though it might pick up the new libraries but that did not seem to be the case. Possibly a configuration error on my part but could be that the eclipse plugin needs re-generating with the new code once you declare 1.2. Probably obvious to you but no harm in mentioning it either way.
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489295 ]
Amila Chinthaka Suriarachchi commented on AXIS2-2246:
-----------------------------------------------------
see your comment on 21/Mar/07 there you have said it is fixed. Actually it is fixed and if it does not work with some wsdl I belive it is also another special case. Please attach the wsdl.
for duplicate element problem I'll put a warning message.
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483282 ]
Tim Buss commented on AXIS2-2246:
---------------------------------
I tried the March 21 07 axis2 snapshot but with the same result. I assume that is what you meant.
I am unclear why this should be a version change in axiom since the latest build of that is 1.2.2. That is what is included in axis2 1.1.1 and none of the axiom libraries or any other dependent libraries are included in the the axis2 SNAPSHOT daily build (in the lib or in the .war) so I can only assume that the same set is required. I copied the dependencies from the axiom 1.2.2 build to be sure and the remainder from axis2 1.1.1 - necessary to get anything to work. Some of the axiom 1.2.2 dependent libs are older versions but that appears to be unimportant.
But despite doing all this there was no change, the apparently correct rpc literal message is sent but and the the same empy fault is returned. I have not tried to debug it.
Perhaps you mean I need to get the latest axiom src and build it to get this to work? I don't really have time to do that right now but I can probably test it if you can give me the updated axiom .jars or include them in the Axis SNAPSHOT build.
On the other problem, by "Document Literal style" message I mean the message contains a qualified element that contains the qualified elements that make up the content (ie no non qualified "parameter" elements) I am not sure about this yet . The wsdl we are using is a bit complex and I would prefer to give you a more focused example.
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489172 ]
Tim Buss commented on AXIS2-2246:
---------------------------------
The fix I am refererring to is the "critical" null namespace for parameter element fix for rpc-literal ws-i compliance that was the original bug. I tried a recent 1.2 snapshot and the fix did not appear to be there. I will try a more recent one when I get time but you may want to check it made it over.
As to the duplicate element issue. My main concern is that the condition should not be allowed to generate code that creates non compliant services as seems to be the case currently. If it is not possible to have axis2 work correctly when this condition occurs then it should generate an error, probably when it tries to create the new element duplicate.
I don't know how axis 1.x. works. I believe it does work in this case because we have a potentially duplicate element defined in the schema and as far as I know we didn't have to do anything special because of that.
> 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
[jira] Updated: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Buss updated AXIS2-2246:
----------------------------
Attachment: Axis2RPCLiteralTest.wsdl
Example WSDL for various simple RPC-literal tests
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489370 ]
Amila Chinthaka Suriarachchi commented on AXIS2-2246:
-----------------------------------------------------
I did not fixed it for 1.1.1 SNAPSHOT. it should be either axis2 trunk (axis2-SNAPSHOT) or axis2 1.2 branch (axis2-1.2-SNAPSHOT). Please have a look at with the RC2.
> 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
[jira] Reopened: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Buss reopened AXIS2-2246:
-----------------------------
We have been testing with the March16, 2007 SNAPSHOT build and I have confirmd that an adb client generated from that build using the wsdl3java command line tool sends the rpc-lit message correctly at least for the example I originally attached to this bug. so siome part of this bug is fixed
However the generated server does not accept this message and instead returns an empty fault like this
<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:Action>http://www.w3.org/2005/08/addressing/soap/fault</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<faultcode></faultcode>
<faultstring></faultstring>
<detail />
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
and the following error is reported:
SEVERE: java.lang.NoSuchMethodError: org.apache.axiom.soap.impl.builder.StAXSOAP
ModelBuilder: method <init>(Ljavax/xml/stream/XMLStreamReader;)V not found
I tried to debug this but unfrotunately I could not get beyond the line
StAXBuilder builder = new StAXSOAPModelBuilder(streamReader);
in SOAPBuilder.processDocument. on the server I was unable to step in and an error is thrown. For some reason I was unable to get the log4J to dispaly DEBUG logs either.
Further we believe that the current fix does not work on more complex schema. It seems that under some circumstance the resulting generated client will send document literal style messages and in that case a working server is created although obviously neither function as intended. I noted this problem with the original bug and I believe we are still seeing it. We have yet to characterize it with a test case.
> 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
[jira] Resolved: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488541 ]
Tim Buss commented on AXIS2-2246:
---------------------------------
It appears that the main fix for this problem has not yet been included in Axis 1.2.
I tried the Axis 1.2 snapshot from 4 April 2007. It inlcudes an apparently later version of axiom but on generating the server with a test I am getting "unexpected element" error on the server at runtime. the error message indicates that it doens't like the rpc parameter element - the one with no namespace.
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485552 ]
Tim Buss commented on AXIS2-2246:
---------------------------------
I have confirmed the attached case is fixed using the AXIOM SNAPSHOT dated 23rd March 2007.
I have still not managed to get a more complex example to work. There seem to be a number of bugs concerning constraints which are getting in my way. In one case the generated code is incorrect and anothere I am still trying to characterize. I will submit a separate bug for those. Probably they are unrelated but I have not managed to confirm that yet.
> 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
[jira] Assigned: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-2246:
----------------------------------------
Assignee: Amila Chinthaka Suriarachchi
> 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
> Assigned To: Amila Chinthaka Suriarachchi
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Tim Buss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489328 ]
Tim Buss commented on AXIS2-2246:
---------------------------------
yes I saw it work for the 1.1.1 snapshot but I have not yet managed to get it to work uisng the 1.2 snapshot using the same WSDL. so I just wanted to be sure the fix had made it into the 1.2 branch. I was wrking on this today so I should know for sure tomorrow. It may be to do with test I am using. Something that worked with Axis 1.X but probably shouldn't have.
> 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
[jira] Commented: (AXIS2-2246) Rpc-Literal Client and Server adb
codegen create messages that are non WS-I complient
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489107 ]
Amila Chinthaka Suriarachchi commented on AXIS2-2246:
-----------------------------------------------------
In this case only the possible option is to give an warning message when generating the code.
In Axis2 we use the element Qname to produce the class name assuming it is unique. ( Does axis 1.x produce sperate classes for two elements?).
> 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