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 <[email protected]> wrote: > >> >> On Oct 16, 2012, at 10:33 PM, Yi Xiao <[email protected]> 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 <[email protected] >>> 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 >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > Best regards! > > > John Xiao
