Return-Path: Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org Received: (qmail 55238 invoked from network); 7 Nov 2006 01:54:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Nov 2006 01:54:17 -0000 Received: (qmail 88891 invoked by uid 500); 7 Nov 2006 01:54:29 -0000 Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org Received: (qmail 88760 invoked by uid 500); 7 Nov 2006 01:54:28 -0000 Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cxf-dev@incubator.apache.org Delivered-To: mailing list cxf-dev@incubator.apache.org Received: (qmail 88745 invoked by uid 99); 7 Nov 2006 01:54:28 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Nov 2006 17:54:28 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of Freeman.Fang@iona.com designates 65.223.216.181 as permitted sender) Received: from [65.223.216.181] (HELO amereast-smg1.iona.com) (65.223.216.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Nov 2006 17:54:14 -0800 Received: from amer-ems1.IONAGLOBAL.COM ([10.65.6.25]) by amereast-smg1.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kA71rVuK021836; Mon, 6 Nov 2006 20:53:31 -0500 (EST) Received: from iona.com ([10.129.9.141]) by amer-ems1.IONAGLOBAL.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 20:53:50 -0500 Message-ID: <454FE707.4090505@iona.com> Date: Tue, 07 Nov 2006 09:53:11 +0800 From: Freeman Fang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cxf-dev@incubator.apache.org CC: cxf-issues@incubator.apache.org Subject: Re: [jira] Commented: (CXF-184) parameter order should be take care of in runtime References: <33027645.1162828599103.JavaMail.jira@brutus> In-Reply-To: <33027645.1162828599103.JavaMail.jira@brutus> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 01:53:51.0486 (UTC) FILETIME=[92D9C9E0:01C7020F] X-Virus-Checked: Checked by ClamAV on apache.org 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