[ http://issues.apache.org/jira/browse/CXF-184?page=comments#action_12447454 ] Peter Jones commented on CXF-184: ---------------------------------
Hi there, I've made some changes in my tree for this bug. In frontend/jaxws: JAXWSMethodInvoker checks the list of SoapHeaderInfo from the exchange to ensure the parameter list and return part list are ordered correctly. In bindings/soap: SoapBindingFactory calls BindingMessageInfo.setMessageParts() with the list of non-header parts. In rt/core: AbstractInDatabindingInterceptor.findMessagePart() uses the BindingOperationInfo's BindingMessageInfo to find the correct non-header part. BareInInterceptor uses the BindingOperationInfo's BindingMessageInfo to read the non-header parts. This fixes my test case, and doesn't break any of the tests. Do these changes sound ok to everyone? Or does anyone see possible issues? > 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
