cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: About the handler chain execution flow
Date Wed, 17 Oct 2012 19:31:54 GMT

On Oct 16, 2012, at 10:33 PM, Yi Xiao <xiaoyijhondevelop@gmail.com> wrote:

> Could someone shed some light on the issue? thank you very much.

Welcome to the world of implementing specs….   If there are multiple ways 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 <xiaoyijhondevelop@gmail.com>wrote:
> 
>> Hi,
>> 
>> Recently, I've tested some handler cases , when I test the case that the
>> 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 return
>> 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 return
>> 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 return
>> 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 cease.
>> Subsequent actions depend
>> on whether the message exchange pattern (MEP) in use requires a response
>> 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


Mime
View raw message