You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Peter Jones <pe...@iona.com> on 2006/10/25 06:47:08 UTC
parameter order in soap messages
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
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: parameter order in soap messages
Posted by Freeman Fang <fr...@iona.com>.
Hi Dan,
I will fix this issue after JBI integration work.
Thanks very much
Freeman
Dan Diephouse wrote:
> I added a note to that issue - but I just wanted to bring it to the
> list so everyone saw: we really need to get rid of
> MessagePartInfo.isInSoapHeader Soon. Can anyone take a look at this
> issue soon?
>
> - Dan
>
> Freeman Fang wrote:
>
>> Hi Peter,
>>
>> It's should be a bug of runtime, I have created a task on jira to
>> track this issue
>>
>> https://issues.apache.org/jira/browse/CXF-184
>>
>> Thanks very much
>>
>> Freeman
>>
>> Peter Jones wrote:
>>
>>> 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
>>>
>>>
>>>
>>
>>
>
>
--
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: parameter order in soap messages
Posted by Dan Diephouse <da...@envoisolutions.com>.
I added a note to that issue - but I just wanted to bring it to the list
so everyone saw: we really need to get rid of
MessagePartInfo.isInSoapHeader Soon. Can anyone take a look at this
issue soon?
- Dan
Freeman Fang wrote:
> Hi Peter,
>
> It's should be a bug of runtime, I have created a task on jira to
> track this issue
>
> https://issues.apache.org/jira/browse/CXF-184
>
> Thanks very much
>
> Freeman
>
> Peter Jones wrote:
>
>> 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
>>
>>
>>
>
>
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
Re: parameter order in soap messages
Posted by Freeman Fang <fr...@iona.com>.
Hi Peter,
It's should be a bug of runtime, I have created a task on jira to track
this issue
https://issues.apache.org/jira/browse/CXF-184
Thanks very much
Freeman
Peter Jones wrote:
>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
>
>
>
--
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