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
[EMAIL PROTECTED]
-------------------------------------------------
Making Software Work Together TM
