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=13646>. 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=13646 WSIFOperation_ApacheAxis fails to set up Call's Parameter list Summary: WSIFOperation_ApacheAxis fails to set up Call's Parameter list Product: Axis Version: current (nightly) Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Basic Architecture AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a version of the WSIF DynamicInvoker client which handles complex types on input and output. A single Java class (wrapping a DOM Element and a QName for its type) serves for all these, and serializer/deserializers are registered on the Call object's TypeMapping. During the generation of the SOAP envelope, bogus elements are generated named arg<i> where i is the 0-based position in the parameter list, wrapping the correct form of each input parameter. These arg<i> can have incorrect xsi:type attributes which arise from looking up the single Java class in the type mapping without a corresponding xml type QName. What appears to be going wrong is this: The addition of the bogus arg0 element to the SOAP envelope comes during the invocation of client.Call.invoke(namespace,method,args). Here, the code attempts to turn the body into an RPCElement, processing the arguments using Call.getParamList(args). But nobody has remembered to set up the parameters of the Call object, so the args are returned unmodified from getParamList, rather than as a list of properly set up RPCParams. The RPCElement constructor invents the element name "argi" for the ith argument if that is not a proper RPCParam. This appears to be a bug in WSIFOperation_ApacheAxis.prepare() or WSIFOperation_ApacheAxis.invokeRequestResponseOperation, more likely the latter, one of which should build up the Parameter descriptors and return type descriptors on the Call object. I suggest the latter because the part descriptors on the input and output messages hold most the necessary info. Calling Call.setOperation would be only a quick fix, since the WSIFOperation and its associated input and output WSIFMessage objects already hold the detailed information about the types and stuff, and has done overload resolution and the like which is superior to what Call.setOperation will do. I will attach the correct SOAP envelope (the Body is the crucial part) produced by the WSIFOperation_ApacheSOAP, and two incorrect ones (for each possible setting of the property org.apache.axis.AxisEngine.PROP_DOMULTIREFS. In the incorrect versions, the type of the bogus arg0 element is ProductInfo, which is the return type, rather than KeywordRequest, which is correct. The test occurs on Amazon's service using http://soap.amazon.com/schemas2/AmazonWebServices.wsdl and the operation KeywordSearchRequest.
