You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Yi Xiao <xi...@gmail.com> on 2012/10/16 05:15:40 UTC
About the handler chain execution flow
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
Re: About the handler chain execution flow
Posted by Freeman Fang <fr...@gmail.com>.
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 <dk...@apache.org> wrote:
>
>>
>> On Oct 16, 2012, at 10:33 PM, Yi Xiao <xi...@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
Re: About the handler chain execution flow
Posted by Freeman Fang <fr...@gmail.com>.
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 <dk...@apache.org> wrote:
>
>>
>> On Oct 16, 2012, at 10:33 PM, Yi Xiao <xi...@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
Re: About the handler chain execution flow
Posted by Yi Xiao <xi...@gmail.com>.
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 <dk...@apache.org> wrote:
>
> On Oct 16, 2012, at 10:33 PM, Yi Xiao <xi...@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
Re: About the handler chain execution flow
Posted by Yi Xiao <xi...@gmail.com>.
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 <dk...@apache.org> wrote:
>
> On Oct 16, 2012, at 10:33 PM, Yi Xiao <xi...@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
Re: About the handler chain execution flow
Posted by Daniel Kulp <dk...@apache.org>.
On Oct 16, 2012, at 10:33 PM, Yi Xiao <xi...@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 <xi...@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
Re: About the handler chain execution flow
Posted by Daniel Kulp <dk...@apache.org>.
On Oct 16, 2012, at 10:33 PM, Yi Xiao <xi...@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 <xi...@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
Re: About the handler chain execution flow
Posted by Yi Xiao <xi...@gmail.com>.
Could someone shed some light on the issue? thank you very much.
On Tue, Oct 16, 2012 at 11:15 AM, Yi Xiao <xi...@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
Re: About the handler chain execution flow
Posted by Yi Xiao <xi...@gmail.com>.
Could someone shed some light on the issue? thank you very much.
On Tue, Oct 16, 2012 at 11:15 AM, Yi Xiao <xi...@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