You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Peter Jones (JIRA)" <ji...@apache.org> on 2006/11/06 16:56:39 UTC
[jira] Commented: (CXF-184) parameter order should be take care of
in runtime
[ 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
Re: [jira] Commented: (CXF-184) parameter order should be take care of in runtime
Posted by Peter Jones <pe...@iona.com>.
Hi Freeman,
On Tue, Nov 07, 2006 at 09:53:11AM +0800, Freeman Fang wrote:
> Hi Peter,
>
> This fix is fine to me.
>
> Would you please upload your patch so that we can test and apply it.
Okay, I just committed the changes. Particularly,
JAXWSMethodInvoker,
BareInInterceptor,
AbstractInDatabindingInterceptor,
SoapBindingFactory and
SoapOutInterceptor
have the pertinent changes. Please let me know what you think.
Cheers,
Peter
> Thanks very much
>
> Freeman
>
>
> Peter Jones (JIRA) wrote:
>
> > [ http://issues.apache.org/jira/browse/CXF-184?page=comments#action_12447454 ]
> >
> >Peter Jones commented on CXF-184:
> >---------------------------------
> [...]
--
Peter Jones
IONA Technologies Inc.
E-Mail: mailto:peter.jones@iona.com
Tel: (w) 709-738-3725 x22 | Fax: 709-738-3745
84-86 Elizabeth Ave. St. John's, NL A1A 1W7 Canada
Re: [jira] Commented: (CXF-184) parameter order should be take care
of in runtime
Posted by Freeman Fang <fr...@iona.com>.
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
Freeman
Peter Jones (JIRA) wrote:
> [ 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
>>
>>
>
>
>
--
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
freeman.fang@iona.com
-------------------------------------------------
Making Software Work Together TM
Re: [jira] Commented: (CXF-184) parameter order should be take care
of in runtime
Posted by Freeman Fang <fr...@iona.com>.
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
Freeman
Peter Jones (JIRA) wrote:
> [ 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
>>
>>
>
>
>
--
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
freeman.fang@iona.com
-------------------------------------------------
Making Software Work Together TM