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=21519>. 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=21519 doc/literal parameters used as service name [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2003-07-13 02:25 ------- I agree with Tom here - this isn't a bug, it's behaving as designed. Check out the SOAPBuilders doc/lit tests from round 3. Let's take the compound1 test as an example (wsdl in test/wsdl/interop3/compound1/Compound1.wsdl). You've got an "echoPerson" operation where the input part is called "x" and the element is {http://soapinterop.org/}x_Person. We decided that the appropriate operation name for this when building stubs is "echoPerson", not in fact "x_Person", and that the *argument* to this operation is the Person structure which maps to the "x_Person" element. Seems right, no? If we want consistent mappings that means we also need to emit WSDL using the same rules. So for "document" services, we assume that any arguments to the Java methods are going to be the parts in the WSDL, and the parts correspond to the element declarations in the generated schema. In other words, we get the "top level" elements being the parameter names. Note that we will happily dispatch to the correct operation as long as there is a unique qname for each such "first parameter". If you want your xml to look like this: <methodName xmlns="foo"> <arg1>53</arg1> <arg2>Some string</arg2> </methodName> ...you have two choices. First, you can use a single parameter to your "document"-style method which is a structure containing "arg1" and "arg2" fields, and you can set the desired QName for the operation in the WSDD (note that the actual Java method name does not necessarily have anything to do with the "methodName" in the XML). Second, you can just use "wrapped" mode instead and get what you expect with a "methodName" method in your Java taking two arguments. I'm marking this invalid for now - if you think there is a real problem, please include a small test case which demonstrates the issue and we'll try to resolve it if we can. Thanks!
