DO NOT REPLY [Bug 13646] New: - WSIFOperation_ApacheAxis fails to set up Call's Parameter list

[bu...@apache.org]

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: axis-dev@xml.apache.org
        ReportedBy: jgreif@alumni.princeton.edu


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.