cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: parameter order in soap messages
Date Mon, 30 Oct 2006 01:57:01 GMT
Hi Dan,

I will fix this issue after JBI integration work.

Thanks very much


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
>> 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
Making Software Work Together TM

View raw message