You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2006/10/27 04:40:16 UTC
[jira] Created: (CXF-184) parameter order should be take care of in
runtime
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
--
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
[jira] Resolved: (CXF-184) parameter order should be take care of
in runtime
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang resolved CXF-184.
------------------------------
Resolution: Fixed
> parameter order should be take care of in runtime
> -------------------------------------------------
>
> Key: CXF-184
> URL: https://issues.apache.org/jira/browse/CXF-184
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0-RC
> Reporter: Freeman Fang
> Assigned To: Freeman Fang
> Fix For: 2.0-RC
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-184) parameter order should be take care of
in runtime
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ 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
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
[jira] Commented: (CXF-184) parameter order should be take care of
in runtime
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ 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
[jira] Assigned: (CXF-184) parameter order should be take care of
in runtime
Posted by "Bozhong Lin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bozhong Lin reassigned CXF-184:
-------------------------------
Assignee: Jervis Liu
> parameter order should be take care of in runtime
> -------------------------------------------------
>
> Key: CXF-184
> URL: https://issues.apache.org/jira/browse/CXF-184
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0-RC
> Reporter: Freeman Fang
> Assigned To: Jervis Liu
> Fix For: 2.0-RC
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-184) parameter order should be take care of in
runtime
Posted by "maomaode (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/CXF-184?page=all ]
maomaode updated CXF-184:
-------------------------
Description:
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
> 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
[jira] Updated: (CXF-184) parameter order should be take care of in
runtime
Posted by "Bozhong Lin (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/CXF-184?page=all ]
Bozhong Lin updated CXF-184:
----------------------------
Fix Version/s: 2.0-RC
Affects Version/s: 2.0-RC
(was: 2.0-M1)
> 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-RC
> Reporter: Freeman Fang
> Fix For: 2.0-RC
>
>
> 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
[jira] Closed: (CXF-184) parameter order should be take care of in
runtime
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang closed CXF-184.
----------------------------
> parameter order should be take care of in runtime
> -------------------------------------------------
>
> Key: CXF-184
> URL: https://issues.apache.org/jira/browse/CXF-184
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0-RC
> Reporter: Freeman Fang
> Assigned To: Freeman Fang
> Fix For: 2.0-RC
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-184) parameter order should be take care of
in runtime
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/CXF-184?page=comments#action_12445403 ]
Dan Diephouse commented on CXF-184:
-----------------------------------
Isn't the parameter order defined in the wsdl binding?
This means that our Binding class should be providing a List of ordered message parts instead of hitting the interface.getMessageParts(). This corresponds to our need to get rid of MessagePartInfo.isInSoapHeader() as thats the complete wrong place for that method. In my mind the Binding should have this method:
List<MessagePartInfo> getMessageParts(OperationInfo op);
The SoapBinding woudl then have this method as well:
List<MessagePartInfo> getHeaderMessageParts(OperationInfo op);
All of these parts would be ordered.
> 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
[jira] Commented: (CXF-184) parameter order should be take care of
in runtime
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/CXF-184?page=comments#action_12445191 ]
Daniel Kulp commented on CXF-184:
---------------------------------
Just a clarification: the parameter order is a function of the frontend, not the SOAP binding or the Bare*Interceptors and such. Those interceptors should be working on the messages as defined in the logical part of the wsdl. Thus, the part order in the messages is how they should appear there.
The JAX-WS frontend (and/or the Simple frontend) should map the parameter order to the correct message based ordering.
Dan K.
> 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
[jira] Assigned: (CXF-184) parameter order should be take care of
in runtime
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang reassigned CXF-184:
--------------------------------
Assignee: Freeman Fang (was: Jervis Liu)
> parameter order should be take care of in runtime
> -------------------------------------------------
>
> Key: CXF-184
> URL: https://issues.apache.org/jira/browse/CXF-184
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.0-RC
> Reporter: Freeman Fang
> Assigned To: Freeman Fang
> Fix For: 2.0-RC
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.