[ http://issues.apache.org/jira/browse/CXF-184?page=comments#action_12445406 ] Daniel Kulp commented on CXF-184: ---------------------------------
The parameter is in the wsdl binding, but per the wsdl spec, the parameter order "serves as a "hint" and may safely be ignored by those not concerned with RPC signatures." (section 2.4.6) Since the SOAP binding (and other bindings) does not know if the frontend is or is not concerned with RPC signatures, it shouldn't rely on parts coming in odered as per what the parameterOrder attribute says. Since the attribute is just a hint to the frontend, the frontend should decide whether to use the hint or not. > parameter order should be take care of in runtime > ------------------------------------------------- > > Key: CXF-184 > URL: http://issues.apache.org/jira/browse/CXF-184 > Project: CXF > Issue Type: Bug > Affects Versions: 2.0-M1 > Reporter: Freeman Fang > > Hi there, > I'm seeing a problem with parameter order in cxf, and just thought I'd > see if anyone else had any insights. > Somewhat related to CXF-161, I was messing around with a test wsdl and > added a parameterOrder attribute to an operation whose output message > contained both a header part and a response part. Unfortunately, the > runtime doesn't quite work correctly when using parameterOrder. (Often > cxf won't find the correct method to call on the server side in this > case). The BareInInterceptor doesn't seem to account for the > parameterOrder list when putting together the parameter list which is > used to invoke on the server - it assumes header parts always come > after all other parameters. > I made a few changes in my tree to make sure the parameter list is > correctly ordered and that seems to make sure the right method gets > invoked. > The problem I'm seeing now though is related to the return type. In my > test wsdl, I left the return part unlisted but listed the header part in > the parameterOrder. > The issue seems to be that when WSDLServiceBuilder.buildMessage() runs > for the out message of the operation, the order for the parts it gets > is 1) header_part 2) return part (since header_part is in the paramOrder > list but the response part isn't). > Later, when the BareOutInterceptor.handleMessage() tries to write the > output arguments, the arguments are in the order 1) return 2) out parameters > (unfortunately not the same as the MessageParts order and so a problem). > Not sure if my description makes sense, but I just wanted to see if > I'm missing something here, or if anyone has any thoughts... :) > Cheers, > Peter > -- Peter Jones -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
