axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17303] - [doc/lit] Invalid WSDL generated when using wrapped/literal
Date Mon, 24 Nov 2003 22:40:32 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17303>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17303

[doc/lit] Invalid WSDL generated when using wrapped/literal

gdaniels@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From gdaniels@apache.org  2003-11-24 22:40 -------
Hi Rick,

I'm marking this FIXED at this point, because the original wrapped problem has 
been fixed for ages, and the doc/lit problem.  Let me explain:

"wrapped" mode, as I'm sure you know, *is* document/literal according to the 
SOAP/WSDL way of looking at things.  The main thing that you gain 
from "wrapped" mode is the fact that the SOAP body contents are wrapped (hence 
the name) with an XML element that represents the operation to be invoked.  
This acts as a container for elements which map to the arguments, and allows 
for easy dispatching to the correct operation via the QName of the wrapper.

When you use "document" style in Axis, there is NO generated wrapper element, 
and so the contents of the SOAP body map to the arguments in your Java method, 
not to the method itself.  This is why we have the ability to specify a 
particular dispatch element in the <operation> descriptor in WSDD, because we 
may end up dispatching an element like <foo> to an operation called "bar" 
(although in these cases something like soapAction is a better choice for 
dispatching anyway).  If you check out the interop3 "compound1" test you can 
see a good example of this - test.wsdl.interop3.compound1.

When using document style like this, the usual pattern is to pass a single 
Java object which represents the whole contents of the SOAP body - and now we 
get to your example.  Since you have two string args, we generate the WSDL as 
if there are two SOAP body elements, and .NET may have a problem with that 
pattern (other than that the WSDL looks basically fine to me, except perhaps 
for the weirdness that the elements <value1>, etc. don't live in a 
namespace).  It doesn't, though, look wrong to me.

As for RPC/literal, the WSDL we produce actually looks right also, but I have 
no idea if it would actually work (we haven't put much energy into that 
code).  This part will become more important now that rpc/lit is part of the 
WS-I BP, so we should test it and open up a separate bug if a known-good 
example fails to work.

Let me know if you have further issues/questions about this stuff.

Mime
View raw message