About the handler chain execution flow

Hi,

Recently, I've tested some handler cases in Axis2, when I test the case
that the handler return *false*, *inbound*,* oneWay* at server side, the
message's execution flow 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

I also test the same case in Glassfish3.1.2.2 and CXF 2.6.2.

(1)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:

*
*

(2)The CXF 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:


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", as the spec said,
the normal message processing should cease, I think the message should
dispatch to client directly but not endpoint.
The Three implementations have three behavior, it's really not painful for
users to migrate their applications.

Could someone explain it? I will be very appreciated :) thank you very much.
-- 
Best regards!


                 John Xiao