Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 73FF0D080 for ; Thu, 18 Oct 2012 04:08:15 +0000 (UTC) Received: (qmail 45213 invoked by uid 500); 18 Oct 2012 04:08:14 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 44872 invoked by uid 500); 18 Oct 2012 04:08:11 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 44815 invoked by uid 99); 18 Oct 2012 04:08:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Oct 2012 04:08:09 +0000 X-ASF-Spam-Status: No, hits=3.1 required=5.0 tests=HK_RANDOM_ENVFROM,HK_RANDOM_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xiaoyijhondevelop@gmail.com designates 209.85.220.169 as permitted sender) Received: from [209.85.220.169] (HELO mail-vc0-f169.google.com) (209.85.220.169) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Oct 2012 04:08:02 +0000 Received: by mail-vc0-f169.google.com with SMTP id fl17so10372517vcb.0 for ; Wed, 17 Oct 2012 21:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WJsnoxeTiR43iXUv811E5U6u3Nou0offTXh1WExbedU=; b=iUQGGNfa+N/VhJbbkVW4uHfnaRmzFAMewdcKqqhHGS3IG+yQ3IGnex+BR2tzXcDQea vPkqPzjeW5yu0fI5IMzda1dfZ41TNv6uvabHi+Rok59LTqzx9/HlWeAqG93WC04zhUvG p0I2G/INsQAVxQHox2ueEUcP9zZaEmJKu6LNVqSbvh1tTEkbDTZvt+ajzwoIlrunbeG+ oqIisVm961pgpvQM2cTOnAnDl93jpjK7p6LqFyaZ+S1oOEdfZZJA165dBPrCjKC6Cxnj jOIzkMFod+Y3xMcK0Qd78BGikCAhDEm8s+cBYMMnG6a7oT9fKxYk+ebzSuO4ruec2CeG /wRA== MIME-Version: 1.0 Received: by 10.52.27.75 with SMTP id r11mr10552733vdg.94.1350533261484; Wed, 17 Oct 2012 21:07:41 -0700 (PDT) Received: by 10.58.178.140 with HTTP; Wed, 17 Oct 2012 21:07:41 -0700 (PDT) In-Reply-To: <2A9ED5C8-98ED-4099-954D-218569F9DE6D@apache.org> References:

<2A9ED5C8-98ED-4099-954D-218569F9DE6D@apache.org> Date: Thu, 18 Oct 2012 12:07:41 +0800 Message-ID: Subject: Re: About the handler chain execution flow From: Yi Xiao To: users@cxf.apache.org, dev@cxf.apache.org Content-Type: multipart/alternative; boundary=20cf307d02604ee3da04cc4d87c8 X-Virus-Checked: Checked by ClamAV on apache.org --20cf307d02604ee3da04cc4d87c8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan, Thank you very much for your response :) Yes, as you said, maybe the spec does not explain it clearly leading to the difference in each implementation, I will double check it. As RI and axis2 dispatch the message to endpoint and there are many users use them before, now want to migrate the applications from them to CXF(like me :)), so could you please consider changing a little in CXF on this behavior? I will be very appreciated. On Thu, Oct 18, 2012 at 3:31 AM, Daniel Kulp wrote: > > On Oct 16, 2012, at 10:33 PM, Yi Xiao wrote= : > > > Could someone shed some light on the issue? thank you very much. > > Welcome to the world of implementing specs=85. If there are multiple wa= ys > to interpret the spec and the TCK for the spec doesn't explicitly test a > particular implementation, there will likely end up as multiple > implementations. Actually, even if the TCK DOES originally test a > particular implementation, if someone can read the spec differently and > interpret it differently, they can usually challenge the TCK and get the > test excluded. > > Dan > > > > On Tue, Oct 16, 2012 at 11:15 AM, Yi Xiao >wrote: > > > >> Hi, > >> > >> Recently, I've tested some handler cases , when I test the case that t= he > >> handler return *false*, *inbound*,* oneWay* at server side, the > message's > >> execution flow in CXF is: > >> > >> Server_SOAPHandler1_handleMessage_Inbound: > >> Server_SOAPHandler2_handleMessage_Inbound: > >> Server_LogicalHandler_handleMessage_Inbound:// The LogicalHandler retu= rn > >> false > >> Server_LogicalHandler_close: > >> Server_SOAPHandler2_close: > >> Server_SOAPHandler1_close: > >> > >> I also test the same case in Axis2 and Glassfish3.1.2.2. > >> > >> (1)The Axis2 result is: > >> > >> Server_SOAPHandler1_handleMessage_Inbound: > >> Server_SOAPHandler2_handleMessage_Inbound: > >> Server_LogicalHandler_handleMessage_Inbound:// The LogicalHandler retu= rn > >> false > >> Server_LogicalHandler_close: > >> Server_SOAPHandler2_close: > >> Server_SOAPHandler1_close: > >> *Server_sendString: *// The message is from endpoint > >> > >> * > >> * > >> > >> (2)The Glassfish result is: > >> > >> Server_SOAPHandler1_handleMessage_Inbound: > >> Server_SOAPHandler2_handleMessage_Inbound: > >> Server_LogicalHandler_handleMessage_Inbound:// The LogicalHandler retu= rn > >> false > >> *Server_sendString: *// The message is from endpoint > >> Server_LogicalHandler_close: > >> Server_SOAPHandler2_close: > >> Server_SOAPHandler1_close: > >> > >> > >> According to the jsr224 9.3.2.1, > >> > >> Return false This indicates that normal message processing should ceas= e. > >> Subsequent actions depend > >> on whether the message exchange pattern (MEP) in use requires a respon= se > >> to the message currently > >> being processed or not: > >> > >> *No response* Normal message processing stops, close is called on each > >> previously invoked handler > >> in the chain, the *message is dispatched* (see section 9.1.2.2). > >> > >> I am not sure about the mean of "message is dispatched", the CXF > dispatch > >> the message to client directly but the Glassfish and Axis2 send the > message > >> to endpoint first. > >> > >> The Three implementations have three behavior, it's really painful for > >> users to migrate their applications. > >> > >> Could someone explain it? I will be very appreciated :) thank you very > >> much. > >> > >> -- > >> Best regards! > >> > >> > >> John Xiao > >> > >> > >> > > > > > > -- > > Best regards! > > > > > > John Xiao > > -- > Daniel Kulp > dkulp@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > --=20 Best regards! John Xiao --20cf307d02604ee3da04cc4d87c8--