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
