You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Yi Xiao <xi...@gmail.com> on 2012/10/16 03:50:44 UTC
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
Re: About the handler chain execution flow
Posted by Yi Xiao <xi...@gmail.com>.
Could someone shed some light on the issue? Thanks very much.
On Tue, Oct 16, 2012 at 9:50 AM, Yi Xiao <xi...@gmail.com>wrote:
> 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 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
Re: About the handler chain execution flow
Posted by Yi Xiao <xi...@gmail.com>.
Could someone shed some light on the issue? Thanks very much.
On Tue, Oct 16, 2012 at 9:50 AM, Yi Xiao <xi...@gmail.com>wrote:
> 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 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