[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
