cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: About the handler chain execution flow
Date Thu, 18 Oct 2012 04:36:39 GMT
Hi,

I'm -1 to change CXF behavior if it's just the vague part of the spec which lead to different
implementation, as we also have a huge user base of CXF community who mostly like depend current
CXF behavior.

Freeman
-------------
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042

On 2012-10-18, at 下午12:07, Yi Xiao wrote:

> 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 <dkulp@apache.org> wrote:
> 
>> 
>> 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
>> 
>> 
> 
> 
> -- 
> Best regards!
> 
> 
>                 John Xiao


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message