Mailing-List: contact cxf-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Message-ID: <13841369.1170998465983.JavaMail.jira@brutus>
Date: Thu, 8 Feb 2007 21:21:05 -0800 (PST)
From: "Freeman Fang (JIRA)" <jira@apache.org>
To: cxf-issues@incubator.apache.org
Subject: [jira] Closed: (CXF-184) parameter order should be take care of in
 runtime
In-Reply-To: <13058741.1161916816568.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.