cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: [jira] Commented: (CXF-184) parameter order should be take care of in runtime
Date Tue, 07 Nov 2006 01:53:11 GMT
Hi Peter,

This fix is fine to me.

Would you please upload your patch so that we can test and apply it.

Thanks very much


Peter Jones (JIRA) wrote:

>    [ ] 
>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
>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
>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:
>>            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
>>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...  :) 
>>-- Peter Jones

Freeman Fang
Software Engineer

IONA Asia Pacific Software Development Center
No.2 Floor A Unit Information Center
Zhongguancun Software Park Haidian District,
Beijing, P.R.China

Tel.: +86-10-82825151 -  ex. 551
Fax: +86-10-8282-5210
Making Software Work Together TM

View raw message