You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "unrealjiang (JIRA)" <ji...@apache.org> on 2007/02/07 08:53:05 UTC
[jira] Created: (CXF-411) Refactoring interceptor chain
Refactoring interceptor chain
-----------------------------
Key: CXF-411
URL: https://issues.apache.org/jira/browse/CXF-411
Project: CXF
Issue Type: Task
Components: Core
Affects Versions: 2.0-RC
Reporter: unrealjiang
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-411) Refactoring interceptor chain
Posted by "Jervis Liu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jervis Liu resolved CXF-411.
----------------------------
Resolution: Fixed
> Refactoring interceptor chain
> -----------------------------
>
> Key: CXF-411
> URL: https://issues.apache.org/jira/browse/CXF-411
> Project: CXF
> Issue Type: Task
> Components: Core
> Affects Versions: 2.0-RC
> Reporter: unrealjiang
> Assigned To: Jervis Liu
> Fix For: 2.0-RC
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Jervis,
This is good reasoning to me, BUT that wasn't what your original email used
as the reasoning for onComplete. You were saying we might want to abort
mid-write and be able to support finishing of writing the message. However
that isn't a valid use case IMO.
Given that, I propose that we do the following:
- Remove handleFault/postHandleMessage from Interceptor interface
- Add an onAbort method to the interceptor interface
Regards,
- Dan
On 3/26/07, Liu, Jervis <jl...@iona.com> wrote:
>
> The main objective of this refactoring is to replace the subchain with
> some enhanced interceptor APIs that allow interceptors to register terminal
> actions on the chain, so that the terminal actions can be called during the
> unwind phase. Given this, it would appear odd to me if we say we support
> unwinding with terminal actions (by using ending interceptors), but this
> wont work when calling interceptorChain.abort(), for various reasons:
> (a). on the inbound direction, the terminal actions do not need to work
> because we do not think any inbound interceptors would need terminal
> actions. (b) For the outbound, the terminal actions do not work as abort()
> essentially means things have been screwed up completely, it does not matter
> anymore if terminal actions are not called ;-). IMO as long as we respect
> the abort() as a valid action on the interceptor chain, as long as we intend
> to design an interceptor API that supports unwinding, we need to make sure
> they work with each other.
>
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 2007年3月26日 21:01
> > To: cxf-dev@incubator.apache.org
> > Cc: cxf-issues@incubator.apache.org
> > Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >
> >
> > Dan Diephouse wrote:
> > > Hiya Jervis,
> > >
> > > Thanks for taking charge. With regards to your service routing case,
> > > we're
> > > simply reading the message and not writing, so I don't
> > thing abort is
> > > going
> > > to cause any problems with ending interceptors.
> > >
> > > As for the HTTP case, looking through the threads it only
> > sounds like
> > > we're
> > > concerned about the 401 case on the server side. In which
> > case we're just
> > > reading a message again, so it shouldn't be any issue to
> > abort. Or do we
> > > need to work with 401s at the interceptor level on the Client side
> > > too? If
> > > so, that sounds kinda odd to me, but I haven't really
> > looked into this at
> > > all either.
> > >
> >
> > I have investigated this extensively. I do not use "abort()" on the
> > client side because the 401 case is not handled strictly in an
> > interceptor, (i.e. not when it's "intercepting"), but down in the
> > Conduit's outputstream, just when the response is received
> > and spawn the
> > Inbound message. Basically at that point, depending on who
> > calls writes
> > to and/or calls close() on the message's output stream
> > governs when this
> > is handled, basically, all Out interceptors may be finished at that
> > point. (Who knows). In any case, the handing of the 401 has
> > no knowledge
> > of interceptors, per se.
> >
> > On the server side, that is a different story. I've taken Eoghan's
> > approach about an interceptor supplying the 401 response code and
> > directly sending the reply back underneath the infrastructure. This
> > approach requires that abort() be called.
> >
> > Cheers,
> > -Polar
> > > The only issue is if we abort() while in the middle of writing.
> > > Wouldn't we
> > > just be completely screwed then anyway? i.e. if we abort sometime
> > > before we
> > > marshal a soap body, but the envelope is completely
> > marshalled, we'll
> > > send
> > > an empty response. Which doesn't sound like the right
> > action at all. If a
> > > user signals an abort() on a write, they should have good reason and
> > > my gut
> > > feeling is we should respect that.
> > >
> > > Cheers,
> > > - Dan
> > >
> > > On 3/25/07, Liu, Jervis <jl...@iona.com> wrote:
> > >>
> > >> Have we decided to remove OnComplete()? Quickly went
> > through the thread
> > >> [1], it shows that we haven't reached any agreement on the
> > proposal yet,
> > >> though there are two approaches have gained their voice. One is
> > >> using OnComplete(), another is without OnComplete(),
> > ending interceptors
> > >> will be needed whenever terminal actions are needed. As Eoghan has
> > >> pointed
> > >> out, there are cases interceptor chain can be aborted in
> > the middle of
> > >> execution thus the "ending interceptors" may never get chance to be
> > >> called -
> > >> This is for HTTP 401 case. Actually I also have a similar
> > use case: when
> > >> writing an interceptor that can do service routing [2], I
> > will need to
> > >> call InterceptorChain.abort() on my dummy service once I
> > have redirected
> > >> the request to the real destination. Provided the cases
> > listed above are
> > >> valid use cases, I would vote for using OnComplete(), as
> > this semantic
> > >> allows for unwinding the chain with onComplete() calls to
> > the already
> > >> traversed interceptors.
> > >>
> > >> Any thoughts? This has been on my to-do-list for a while, so I will
> > >> definitely be volunteering to do this work.
> > >>
> > >> Cheers,
> > >> Jervis
> > >>
> > >> [1].
> > >>
> > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> 702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> >>
> >> [2]:
> http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
> >>
> >> > -----Original Message-----
> >> > From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> >> > Sent: 2007年3月26日 9:43
> >> > To: cxf-issues@incubator.apache.org
> >> > Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >> >
> >> >
> >> >
> >> > [
> >> > https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
> >> > an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
> >> > 2483994 ]
> >> >
> >> > Dan Diephouse commented on CXF-411:
> >> > -----------------------------------
> >> >
> >> > I think we decided that we need to get postHandleMessage
> >> > removed now. Any volunteers?
> >> >
> >> > > Refactoring interceptor chain
> >> > > -----------------------------
> >> > >
> >> > > Key: CXF-411
> >> > > URL: https://issues.apache.org/jira/browse/CXF-411
> >> > > Project: CXF
> >> > > Issue Type: Task
> >> > > Components: Core
> >> > > Affects Versions: 2.0-RC
> >> > > Reporter: unrealjiang
> >> > > Assigned To: Jervis Liu
> >> > > Fix For: 2.0-RC
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > This message is automatically generated by JIRA.
> >> > -
> >> > You can reply to this email to add a comment to the issue online.
> >> >
> >> >
> >>
> >
> >
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Jervis,
This is good reasoning to me, BUT that wasn't what your original email used
as the reasoning for onComplete. You were saying we might want to abort
mid-write and be able to support finishing of writing the message. However
that isn't a valid use case IMO.
Given that, I propose that we do the following:
- Remove handleFault/postHandleMessage from Interceptor interface
- Add an onAbort method to the interceptor interface
Regards,
- Dan
On 3/26/07, Liu, Jervis <jl...@iona.com> wrote:
>
> The main objective of this refactoring is to replace the subchain with
> some enhanced interceptor APIs that allow interceptors to register terminal
> actions on the chain, so that the terminal actions can be called during the
> unwind phase. Given this, it would appear odd to me if we say we support
> unwinding with terminal actions (by using ending interceptors), but this
> wont work when calling interceptorChain.abort(), for various reasons:
> (a). on the inbound direction, the terminal actions do not need to work
> because we do not think any inbound interceptors would need terminal
> actions. (b) For the outbound, the terminal actions do not work as abort()
> essentially means things have been screwed up completely, it does not matter
> anymore if terminal actions are not called ;-). IMO as long as we respect
> the abort() as a valid action on the interceptor chain, as long as we intend
> to design an interceptor API that supports unwinding, we need to make sure
> they work with each other.
>
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 2007年3月26日 21:01
> > To: cxf-dev@incubator.apache.org
> > Cc: cxf-issues@incubator.apache.org
> > Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >
> >
> > Dan Diephouse wrote:
> > > Hiya Jervis,
> > >
> > > Thanks for taking charge. With regards to your service routing case,
> > > we're
> > > simply reading the message and not writing, so I don't
> > thing abort is
> > > going
> > > to cause any problems with ending interceptors.
> > >
> > > As for the HTTP case, looking through the threads it only
> > sounds like
> > > we're
> > > concerned about the 401 case on the server side. In which
> > case we're just
> > > reading a message again, so it shouldn't be any issue to
> > abort. Or do we
> > > need to work with 401s at the interceptor level on the Client side
> > > too? If
> > > so, that sounds kinda odd to me, but I haven't really
> > looked into this at
> > > all either.
> > >
> >
> > I have investigated this extensively. I do not use "abort()" on the
> > client side because the 401 case is not handled strictly in an
> > interceptor, (i.e. not when it's "intercepting"), but down in the
> > Conduit's outputstream, just when the response is received
> > and spawn the
> > Inbound message. Basically at that point, depending on who
> > calls writes
> > to and/or calls close() on the message's output stream
> > governs when this
> > is handled, basically, all Out interceptors may be finished at that
> > point. (Who knows). In any case, the handing of the 401 has
> > no knowledge
> > of interceptors, per se.
> >
> > On the server side, that is a different story. I've taken Eoghan's
> > approach about an interceptor supplying the 401 response code and
> > directly sending the reply back underneath the infrastructure. This
> > approach requires that abort() be called.
> >
> > Cheers,
> > -Polar
> > > The only issue is if we abort() while in the middle of writing.
> > > Wouldn't we
> > > just be completely screwed then anyway? i.e. if we abort sometime
> > > before we
> > > marshal a soap body, but the envelope is completely
> > marshalled, we'll
> > > send
> > > an empty response. Which doesn't sound like the right
> > action at all. If a
> > > user signals an abort() on a write, they should have good reason and
> > > my gut
> > > feeling is we should respect that.
> > >
> > > Cheers,
> > > - Dan
> > >
> > > On 3/25/07, Liu, Jervis <jl...@iona.com> wrote:
> > >>
> > >> Have we decided to remove OnComplete()? Quickly went
> > through the thread
> > >> [1], it shows that we haven't reached any agreement on the
> > proposal yet,
> > >> though there are two approaches have gained their voice. One is
> > >> using OnComplete(), another is without OnComplete(),
> > ending interceptors
> > >> will be needed whenever terminal actions are needed. As Eoghan has
> > >> pointed
> > >> out, there are cases interceptor chain can be aborted in
> > the middle of
> > >> execution thus the "ending interceptors" may never get chance to be
> > >> called -
> > >> This is for HTTP 401 case. Actually I also have a similar
> > use case: when
> > >> writing an interceptor that can do service routing [2], I
> > will need to
> > >> call InterceptorChain.abort() on my dummy service once I
> > have redirected
> > >> the request to the real destination. Provided the cases
> > listed above are
> > >> valid use cases, I would vote for using OnComplete(), as
> > this semantic
> > >> allows for unwinding the chain with onComplete() calls to
> > the already
> > >> traversed interceptors.
> > >>
> > >> Any thoughts? This has been on my to-do-list for a while, so I will
> > >> definitely be volunteering to do this work.
> > >>
> > >> Cheers,
> > >> Jervis
> > >>
> > >> [1].
> > >>
> > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> 702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> >>
> >> [2]:
> http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
> >>
> >> > -----Original Message-----
> >> > From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> >> > Sent: 2007年3月26日 9:43
> >> > To: cxf-issues@incubator.apache.org
> >> > Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >> >
> >> >
> >> >
> >> > [
> >> > https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
> >> > an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
> >> > 2483994 ]
> >> >
> >> > Dan Diephouse commented on CXF-411:
> >> > -----------------------------------
> >> >
> >> > I think we decided that we need to get postHandleMessage
> >> > removed now. Any volunteers?
> >> >
> >> > > Refactoring interceptor chain
> >> > > -----------------------------
> >> > >
> >> > > Key: CXF-411
> >> > > URL: https://issues.apache.org/jira/browse/CXF-411
> >> > > Project: CXF
> >> > > Issue Type: Task
> >> > > Components: Core
> >> > > Affects Versions: 2.0-RC
> >> > > Reporter: unrealjiang
> >> > > Assigned To: Jervis Liu
> >> > > Fix For: 2.0-RC
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > This message is automatically generated by JIRA.
> >> > -
> >> > You can reply to this email to add a comment to the issue online.
> >> >
> >> >
> >>
> >
> >
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by "Liu, Jervis" <jl...@iona.com>.
The main objective of this refactoring is to replace the subchain with some enhanced interceptor APIs that allow interceptors to register terminal actions on the chain, so that the terminal actions can be called during the unwind phase. Given this, it would appear odd to me if we say we support unwinding with terminal actions (by using ending interceptors), but this wont work when calling interceptorChain.abort(), for various reasons: (a). on the inbound direction, the terminal actions do not need to work because we do not think any inbound interceptors would need terminal actions. (b) For the outbound, the terminal actions do not work as abort() essentially means things have been screwed up completely, it does not matter anymore if terminal actions are not called ;-). IMO as long as we respect the abort() as a valid action on the interceptor chain, as long as we intend to design an interceptor API that supports unwinding, we need to make sure they work with each other.
Cheers,
Jervis
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 2007年3月26日 21:01
> To: cxf-dev@incubator.apache.org
> Cc: cxf-issues@incubator.apache.org
> Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
>
>
> Dan Diephouse wrote:
> > Hiya Jervis,
> >
> > Thanks for taking charge. With regards to your service routing case,
> > we're
> > simply reading the message and not writing, so I don't
> thing abort is
> > going
> > to cause any problems with ending interceptors.
> >
> > As for the HTTP case, looking through the threads it only
> sounds like
> > we're
> > concerned about the 401 case on the server side. In which
> case we're just
> > reading a message again, so it shouldn't be any issue to
> abort. Or do we
> > need to work with 401s at the interceptor level on the Client side
> > too? If
> > so, that sounds kinda odd to me, but I haven't really
> looked into this at
> > all either.
> >
>
> I have investigated this extensively. I do not use "abort()" on the
> client side because the 401 case is not handled strictly in an
> interceptor, (i.e. not when it's "intercepting"), but down in the
> Conduit's outputstream, just when the response is received
> and spawn the
> Inbound message. Basically at that point, depending on who
> calls writes
> to and/or calls close() on the message's output stream
> governs when this
> is handled, basically, all Out interceptors may be finished at that
> point. (Who knows). In any case, the handing of the 401 has
> no knowledge
> of interceptors, per se.
>
> On the server side, that is a different story. I've taken Eoghan's
> approach about an interceptor supplying the 401 response code and
> directly sending the reply back underneath the infrastructure. This
> approach requires that abort() be called.
>
> Cheers,
> -Polar
> > The only issue is if we abort() while in the middle of writing.
> > Wouldn't we
> > just be completely screwed then anyway? i.e. if we abort sometime
> > before we
> > marshal a soap body, but the envelope is completely
> marshalled, we'll
> > send
> > an empty response. Which doesn't sound like the right
> action at all. If a
> > user signals an abort() on a write, they should have good reason and
> > my gut
> > feeling is we should respect that.
> >
> > Cheers,
> > - Dan
> >
> > On 3/25/07, Liu, Jervis <jl...@iona.com> wrote:
> >>
> >> Have we decided to remove OnComplete()? Quickly went
> through the thread
> >> [1], it shows that we haven't reached any agreement on the
> proposal yet,
> >> though there are two approaches have gained their voice. One is
> >> using OnComplete(), another is without OnComplete(),
> ending interceptors
> >> will be needed whenever terminal actions are needed. As Eoghan has
> >> pointed
> >> out, there are cases interceptor chain can be aborted in
> the middle of
> >> execution thus the "ending interceptors" may never get chance to be
> >> called -
> >> This is for HTTP 401 case. Actually I also have a similar
> use case: when
> >> writing an interceptor that can do service routing [2], I
> will need to
> >> call InterceptorChain.abort() on my dummy service once I
> have redirected
> >> the request to the real destination. Provided the cases
> listed above are
> >> valid use cases, I would vote for using OnComplete(), as
> this semantic
> >> allows for unwinding the chain with onComplete() calls to
> the already
> >> traversed interceptors.
> >>
> >> Any thoughts? This has been on my to-do-list for a while, so I will
> >> definitely be volunteering to do this work.
> >>
> >> Cheers,
> >> Jervis
> >>
> >> [1].
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
>>
>> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>>
>> > -----Original Message-----
>> > From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
>> > Sent: 2007年3月26日 9:43
>> > To: cxf-issues@incubator.apache.org
>> > Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>> >
>> >
>> >
>> > [
>> > https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
>> > an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
>> > 2483994 ]
>> >
>> > Dan Diephouse commented on CXF-411:
>> > -----------------------------------
>> >
>> > I think we decided that we need to get postHandleMessage
>> > removed now. Any volunteers?
>> >
>> > > Refactoring interceptor chain
>> > > -----------------------------
>> > >
>> > > Key: CXF-411
>> > > URL: https://issues.apache.org/jira/browse/CXF-411
>> > > Project: CXF
>> > > Issue Type: Task
>> > > Components: Core
>> > > Affects Versions: 2.0-RC
>> > > Reporter: unrealjiang
>> > > Assigned To: Jervis Liu
>> > > Fix For: 2.0-RC
>> > >
>> > >
>> >
>> >
>> > --
>> > This message is automatically generated by JIRA.
>> > -
>> > You can reply to this email to add a comment to the issue online.
>> >
>> >
>>
>
>
>
RE: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by "Liu, Jervis" <jl...@iona.com>.
The main objective of this refactoring is to replace the subchain with some enhanced interceptor APIs that allow interceptors to register terminal actions on the chain, so that the terminal actions can be called during the unwind phase. Given this, it would appear odd to me if we say we support unwinding with terminal actions (by using ending interceptors), but this wont work when calling interceptorChain.abort(), for various reasons: (a). on the inbound direction, the terminal actions do not need to work because we do not think any inbound interceptors would need terminal actions. (b) For the outbound, the terminal actions do not work as abort() essentially means things have been screwed up completely, it does not matter anymore if terminal actions are not called ;-). IMO as long as we respect the abort() as a valid action on the interceptor chain, as long as we intend to design an interceptor API that supports unwinding, we need to make sure they work with each other.
Cheers,
Jervis
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 2007年3月26日 21:01
> To: cxf-dev@incubator.apache.org
> Cc: cxf-issues@incubator.apache.org
> Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
>
>
> Dan Diephouse wrote:
> > Hiya Jervis,
> >
> > Thanks for taking charge. With regards to your service routing case,
> > we're
> > simply reading the message and not writing, so I don't
> thing abort is
> > going
> > to cause any problems with ending interceptors.
> >
> > As for the HTTP case, looking through the threads it only
> sounds like
> > we're
> > concerned about the 401 case on the server side. In which
> case we're just
> > reading a message again, so it shouldn't be any issue to
> abort. Or do we
> > need to work with 401s at the interceptor level on the Client side
> > too? If
> > so, that sounds kinda odd to me, but I haven't really
> looked into this at
> > all either.
> >
>
> I have investigated this extensively. I do not use "abort()" on the
> client side because the 401 case is not handled strictly in an
> interceptor, (i.e. not when it's "intercepting"), but down in the
> Conduit's outputstream, just when the response is received
> and spawn the
> Inbound message. Basically at that point, depending on who
> calls writes
> to and/or calls close() on the message's output stream
> governs when this
> is handled, basically, all Out interceptors may be finished at that
> point. (Who knows). In any case, the handing of the 401 has
> no knowledge
> of interceptors, per se.
>
> On the server side, that is a different story. I've taken Eoghan's
> approach about an interceptor supplying the 401 response code and
> directly sending the reply back underneath the infrastructure. This
> approach requires that abort() be called.
>
> Cheers,
> -Polar
> > The only issue is if we abort() while in the middle of writing.
> > Wouldn't we
> > just be completely screwed then anyway? i.e. if we abort sometime
> > before we
> > marshal a soap body, but the envelope is completely
> marshalled, we'll
> > send
> > an empty response. Which doesn't sound like the right
> action at all. If a
> > user signals an abort() on a write, they should have good reason and
> > my gut
> > feeling is we should respect that.
> >
> > Cheers,
> > - Dan
> >
> > On 3/25/07, Liu, Jervis <jl...@iona.com> wrote:
> >>
> >> Have we decided to remove OnComplete()? Quickly went
> through the thread
> >> [1], it shows that we haven't reached any agreement on the
> proposal yet,
> >> though there are two approaches have gained their voice. One is
> >> using OnComplete(), another is without OnComplete(),
> ending interceptors
> >> will be needed whenever terminal actions are needed. As Eoghan has
> >> pointed
> >> out, there are cases interceptor chain can be aborted in
> the middle of
> >> execution thus the "ending interceptors" may never get chance to be
> >> called -
> >> This is for HTTP 401 case. Actually I also have a similar
> use case: when
> >> writing an interceptor that can do service routing [2], I
> will need to
> >> call InterceptorChain.abort() on my dummy service once I
> have redirected
> >> the request to the real destination. Provided the cases
> listed above are
> >> valid use cases, I would vote for using OnComplete(), as
> this semantic
> >> allows for unwinding the chain with onComplete() calls to
> the already
> >> traversed interceptors.
> >>
> >> Any thoughts? This has been on my to-do-list for a while, so I will
> >> definitely be volunteering to do this work.
> >>
> >> Cheers,
> >> Jervis
> >>
> >> [1].
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
>>
>> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>>
>> > -----Original Message-----
>> > From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
>> > Sent: 2007年3月26日 9:43
>> > To: cxf-issues@incubator.apache.org
>> > Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>> >
>> >
>> >
>> > [
>> > https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
>> > an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
>> > 2483994 ]
>> >
>> > Dan Diephouse commented on CXF-411:
>> > -----------------------------------
>> >
>> > I think we decided that we need to get postHandleMessage
>> > removed now. Any volunteers?
>> >
>> > > Refactoring interceptor chain
>> > > -----------------------------
>> > >
>> > > Key: CXF-411
>> > > URL: https://issues.apache.org/jira/browse/CXF-411
>> > > Project: CXF
>> > > Issue Type: Task
>> > > Components: Core
>> > > Affects Versions: 2.0-RC
>> > > Reporter: unrealjiang
>> > > Assigned To: Jervis Liu
>> > > Fix For: 2.0-RC
>> > >
>> > >
>> >
>> >
>> > --
>> > This message is automatically generated by JIRA.
>> > -
>> > You can reply to this email to add a comment to the issue online.
>> >
>> >
>>
>
>
>
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Polar Humenn <ph...@iona.com>.
Dan Diephouse wrote:
> Hiya Jervis,
>
> Thanks for taking charge. With regards to your service routing case,
> we're
> simply reading the message and not writing, so I don't thing abort is
> going
> to cause any problems with ending interceptors.
>
> As for the HTTP case, looking through the threads it only sounds like
> we're
> concerned about the 401 case on the server side. In which case we're just
> reading a message again, so it shouldn't be any issue to abort. Or do we
> need to work with 401s at the interceptor level on the Client side
> too? If
> so, that sounds kinda odd to me, but I haven't really looked into this at
> all either.
>
I have investigated this extensively. I do not use "abort()" on the
client side because the 401 case is not handled strictly in an
interceptor, (i.e. not when it's "intercepting"), but down in the
Conduit's outputstream, just when the response is received and spawn the
Inbound message. Basically at that point, depending on who calls writes
to and/or calls close() on the message's output stream governs when this
is handled, basically, all Out interceptors may be finished at that
point. (Who knows). In any case, the handing of the 401 has no knowledge
of interceptors, per se.
On the server side, that is a different story. I've taken Eoghan's
approach about an interceptor supplying the 401 response code and
directly sending the reply back underneath the infrastructure. This
approach requires that abort() be called.
Cheers,
-Polar
> The only issue is if we abort() while in the middle of writing.
> Wouldn't we
> just be completely screwed then anyway? i.e. if we abort sometime
> before we
> marshal a soap body, but the envelope is completely marshalled, we'll
> send
> an empty response. Which doesn't sound like the right action at all. If a
> user signals an abort() on a write, they should have good reason and
> my gut
> feeling is we should respect that.
>
> Cheers,
> - Dan
>
> On 3/25/07, Liu, Jervis <jl...@iona.com> wrote:
>>
>> Have we decided to remove OnComplete()? Quickly went through the thread
>> [1], it shows that we haven't reached any agreement on the proposal yet,
>> though there are two approaches have gained their voice. One is
>> using OnComplete(), another is without OnComplete(), ending interceptors
>> will be needed whenever terminal actions are needed. As Eoghan has
>> pointed
>> out, there are cases interceptor chain can be aborted in the middle of
>> execution thus the "ending interceptors" may never get chance to be
>> called -
>> This is for HTTP 401 case. Actually I also have a similar use case: when
>> writing an interceptor that can do service routing [2], I will need to
>> call InterceptorChain.abort() on my dummy service once I have redirected
>> the request to the real destination. Provided the cases listed above are
>> valid use cases, I would vote for using OnComplete(), as this semantic
>> allows for unwinding the chain with onComplete() calls to the already
>> traversed interceptors.
>>
>> Any thoughts? This has been on my to-do-list for a while, so I will
>> definitely be volunteering to do this work.
>>
>> Cheers,
>> Jervis
>>
>> [1].
>> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
>>
>> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>>
>> > -----Original Message-----
>> > From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
>> > Sent: 2007年3月26日 9:43
>> > To: cxf-issues@incubator.apache.org
>> > Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>> >
>> >
>> >
>> > [
>> > https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
>> > an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
>> > 2483994 ]
>> >
>> > Dan Diephouse commented on CXF-411:
>> > -----------------------------------
>> >
>> > I think we decided that we need to get postHandleMessage
>> > removed now. Any volunteers?
>> >
>> > > Refactoring interceptor chain
>> > > -----------------------------
>> > >
>> > > Key: CXF-411
>> > > URL: https://issues.apache.org/jira/browse/CXF-411
>> > > Project: CXF
>> > > Issue Type: Task
>> > > Components: Core
>> > > Affects Versions: 2.0-RC
>> > > Reporter: unrealjiang
>> > > Assigned To: Jervis Liu
>> > > Fix For: 2.0-RC
>> > >
>> > >
>> >
>> >
>> > --
>> > This message is automatically generated by JIRA.
>> > -
>> > You can reply to this email to add a comment to the issue online.
>> >
>> >
>>
>
>
>
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hiya Jervis,
Thanks for taking charge. With regards to your service routing case, we're
simply reading the message and not writing, so I don't thing abort is going
to cause any problems with ending interceptors.
As for the HTTP case, looking through the threads it only sounds like we're
concerned about the 401 case on the server side. In which case we're just
reading a message again, so it shouldn't be any issue to abort. Or do we
need to work with 401s at the interceptor level on the Client side too? If
so, that sounds kinda odd to me, but I haven't really looked into this at
all either.
The only issue is if we abort() while in the middle of writing. Wouldn't we
just be completely screwed then anyway? i.e. if we abort sometime before we
marshal a soap body, but the envelope is completely marshalled, we'll send
an empty response. Which doesn't sound like the right action at all. If a
user signals an abort() on a write, they should have good reason and my gut
feeling is we should respect that.
Cheers,
- Dan
On 3/25/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Have we decided to remove OnComplete()? Quickly went through the thread
> [1], it shows that we haven't reached any agreement on the proposal yet,
> though there are two approaches have gained their voice. One is
> using OnComplete(), another is without OnComplete(), ending interceptors
> will be needed whenever terminal actions are needed. As Eoghan has pointed
> out, there are cases interceptor chain can be aborted in the middle of
> execution thus the "ending interceptors" may never get chance to be called -
> This is for HTTP 401 case. Actually I also have a similar use case: when
> writing an interceptor that can do service routing [2], I will need to
> call InterceptorChain.abort() on my dummy service once I have redirected
> the request to the real destination. Provided the cases listed above are
> valid use cases, I would vote for using OnComplete(), as this semantic
> allows for unwinding the chain with onComplete() calls to the already
> traversed interceptors.
>
> Any thoughts? This has been on my to-do-list for a while, so I will
> definitely be volunteering to do this work.
>
> Cheers,
> Jervis
>
> [1].
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>
> > -----Original Message-----
> > From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> > Sent: 2007年3月26日 9:43
> > To: cxf-issues@incubator.apache.org
> > Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >
> >
> >
> > [
> > https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
> > an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
> > 2483994 ]
> >
> > Dan Diephouse commented on CXF-411:
> > -----------------------------------
> >
> > I think we decided that we need to get postHandleMessage
> > removed now. Any volunteers?
> >
> > > Refactoring interceptor chain
> > > -----------------------------
> > >
> > > Key: CXF-411
> > > URL: https://issues.apache.org/jira/browse/CXF-411
> > > Project: CXF
> > > Issue Type: Task
> > > Components: Core
> > > Affects Versions: 2.0-RC
> > > Reporter: unrealjiang
> > > Assigned To: Jervis Liu
> > > Fix For: 2.0-RC
> > >
> > >
> >
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hiya Jervis,
Thanks for taking charge. With regards to your service routing case, we're
simply reading the message and not writing, so I don't thing abort is going
to cause any problems with ending interceptors.
As for the HTTP case, looking through the threads it only sounds like we're
concerned about the 401 case on the server side. In which case we're just
reading a message again, so it shouldn't be any issue to abort. Or do we
need to work with 401s at the interceptor level on the Client side too? If
so, that sounds kinda odd to me, but I haven't really looked into this at
all either.
The only issue is if we abort() while in the middle of writing. Wouldn't we
just be completely screwed then anyway? i.e. if we abort sometime before we
marshal a soap body, but the envelope is completely marshalled, we'll send
an empty response. Which doesn't sound like the right action at all. If a
user signals an abort() on a write, they should have good reason and my gut
feeling is we should respect that.
Cheers,
- Dan
On 3/25/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Have we decided to remove OnComplete()? Quickly went through the thread
> [1], it shows that we haven't reached any agreement on the proposal yet,
> though there are two approaches have gained their voice. One is
> using OnComplete(), another is without OnComplete(), ending interceptors
> will be needed whenever terminal actions are needed. As Eoghan has pointed
> out, there are cases interceptor chain can be aborted in the middle of
> execution thus the "ending interceptors" may never get chance to be called -
> This is for HTTP 401 case. Actually I also have a similar use case: when
> writing an interceptor that can do service routing [2], I will need to
> call InterceptorChain.abort() on my dummy service once I have redirected
> the request to the real destination. Provided the cases listed above are
> valid use cases, I would vote for using OnComplete(), as this semantic
> allows for unwinding the chain with onComplete() calls to the already
> traversed interceptors.
>
> Any thoughts? This has been on my to-do-list for a while, so I will
> definitely be volunteering to do this work.
>
> Cheers,
> Jervis
>
> [1].
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>
> > -----Original Message-----
> > From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> > Sent: 2007年3月26日 9:43
> > To: cxf-issues@incubator.apache.org
> > Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >
> >
> >
> > [
> > https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
> > an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
> > 2483994 ]
> >
> > Dan Diephouse commented on CXF-411:
> > -----------------------------------
> >
> > I think we decided that we need to get postHandleMessage
> > removed now. Any volunteers?
> >
> > > Refactoring interceptor chain
> > > -----------------------------
> > >
> > > Key: CXF-411
> > > URL: https://issues.apache.org/jira/browse/CXF-411
> > > Project: CXF
> > > Issue Type: Task
> > > Components: Core
> > > Affects Versions: 2.0-RC
> > > Reporter: unrealjiang
> > > Assigned To: Jervis Liu
> > > Fix For: 2.0-RC
> > >
> > >
> >
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Dan Diephouse <da...@envoisolutions.com>.
Sounds good! BTW, I started going down the non-subchain approach with the
SAAJ*Interceptors. It does seem to work quite well, so I'm anxious to get
rid of the uglier sub chain stuff (I know we all are ;-)).
- Dan
On 3/27/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Are we suggesting that we take the "ending interceptors" approach as the
> replacement to subchain invocation, then we add an interceptor.onAbort()
> to handle the situation where interceptorChain.abort() is called but these
> already traversed interceptors still have some resources to close or some
> terminal actions to take before the chain can be gracefully shut down. I
> view this as a good compromise if the performance or semantic complexity is
> really a concern. In this case, I would suggest we don't add
> interceptor.onAbort() at least for the time being. as for these scenarios
> which we believe "ending interceptors" do not work, we do not have any valid
> use case to prove that we need "ending interceptors" in the first place:
> in-bound reading, we don't know any use case that an interceptor needs a
> terminal action; out-bound writing, we don't know a use case that an
> interceptor still need to call its terminal action when the chain is
> aborted. We are free to add such APIs when real requirement arrives.
>
> .
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 2007年3月27日 21:15
> > To: cxf-dev@incubator.apache.org
> > Cc: cxf-issues@incubator.apache.org
> > Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >
> >
> > I think OnComplete provides an unnecessary inefficiency semantic for
> > interceptors. When an "OnComplete" exists, then the interceptor is
> > forced to service it, whether it wants it or not, all the
> > time. Why make
> > the call? That's inefficient.
> >
> > These interceptors are "one-way" unlike CORBA ones, which are two-way
> > (request/reply).
> > So you can give the interceptors a more proactive, preemptive
> > semantic
> > in that the interceptor *assumes* the calls have followed
> > through to the
> > end, *unless* told otherwise, i.e. somebody called
> > InterceptorChain.abort(). That's not an unreasonable
> > assumption, and it
> > avoids having to making calls to OnComplete.
> >
> > Perhaps an "OnAbort" is more appropriate.
> >
> > Cheers,
> > -Polar
> >
> >
> > Liu, Jervis wrote:
> > > Have we decided to remove OnComplete()? Quickly went
> > through the thread [1], it shows that we haven't reached any
> > agreement on the proposal yet, though there are two
> > approaches have gained their voice. One is using
> > OnComplete(), another is without OnComplete(), ending
> > interceptors will be needed whenever terminal actions are
> > needed. As Eoghan has pointed out, there are cases
> > interceptor chain can be aborted in the middle of execution
> > thus the "ending interceptors" may never get chance to be
> > called - This is for HTTP 401 case. Actually I also have a
> > similar use case: when writing an interceptor that can do
> > service routing [2], I will need to call
> > InterceptorChain.abort() on my dummy service once I have
> > redirected the request to the real destination. Provided the
> > cases listed above are valid use cases, I would vote for
> > using OnComplete(), as this semantic allows for unwinding the
> > chain with onComplete() calls to the already traversed interceptors.
> > >
> > > Any thoughts? This has been on my to-do-list for a while,
> > so I will definitely be volunteering to do this work.
> > >
> > > Cheers,
> > > Jervis
> > >
> > > [1].
> > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> 702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> > [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
> >
> >
> >> -----Original Message-----
> >> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> >> Sent: 2007年3月26日 9:43
> >> To: cxf-issues@incubator.apache.org
> >> Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >>
> >>
> >>
> >> [
> >> https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
> >> an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
> >> 2483994 ]
> >>
> >> Dan Diephouse commented on CXF-411:
> >> -----------------------------------
> >>
> >> I think we decided that we need to get postHandleMessage
> >> removed now. Any volunteers?
> >>
> >>
> >>> Refactoring interceptor chain
> >>> -----------------------------
> >>>
> >>> Key: CXF-411
> >>> URL: https://issues.apache.org/jira/browse/CXF-411
> >>> Project: CXF
> >>> Issue Type: Task
> >>> Components: Core
> >>> Affects Versions: 2.0-RC
> >>> Reporter: unrealjiang
> >>> Assigned To: Jervis Liu
> >>> Fix For: 2.0-RC
> >>>
> >>>
> >>>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >>
> >>
> >>
>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Dan Diephouse <da...@envoisolutions.com>.
Sounds good! BTW, I started going down the non-subchain approach with the
SAAJ*Interceptors. It does seem to work quite well, so I'm anxious to get
rid of the uglier sub chain stuff (I know we all are ;-)).
- Dan
On 3/27/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Are we suggesting that we take the "ending interceptors" approach as the
> replacement to subchain invocation, then we add an interceptor.onAbort()
> to handle the situation where interceptorChain.abort() is called but these
> already traversed interceptors still have some resources to close or some
> terminal actions to take before the chain can be gracefully shut down. I
> view this as a good compromise if the performance or semantic complexity is
> really a concern. In this case, I would suggest we don't add
> interceptor.onAbort() at least for the time being. as for these scenarios
> which we believe "ending interceptors" do not work, we do not have any valid
> use case to prove that we need "ending interceptors" in the first place:
> in-bound reading, we don't know any use case that an interceptor needs a
> terminal action; out-bound writing, we don't know a use case that an
> interceptor still need to call its terminal action when the chain is
> aborted. We are free to add such APIs when real requirement arrives.
>
> .
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 2007年3月27日 21:15
> > To: cxf-dev@incubator.apache.org
> > Cc: cxf-issues@incubator.apache.org
> > Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >
> >
> > I think OnComplete provides an unnecessary inefficiency semantic for
> > interceptors. When an "OnComplete" exists, then the interceptor is
> > forced to service it, whether it wants it or not, all the
> > time. Why make
> > the call? That's inefficient.
> >
> > These interceptors are "one-way" unlike CORBA ones, which are two-way
> > (request/reply).
> > So you can give the interceptors a more proactive, preemptive
> > semantic
> > in that the interceptor *assumes* the calls have followed
> > through to the
> > end, *unless* told otherwise, i.e. somebody called
> > InterceptorChain.abort(). That's not an unreasonable
> > assumption, and it
> > avoids having to making calls to OnComplete.
> >
> > Perhaps an "OnAbort" is more appropriate.
> >
> > Cheers,
> > -Polar
> >
> >
> > Liu, Jervis wrote:
> > > Have we decided to remove OnComplete()? Quickly went
> > through the thread [1], it shows that we haven't reached any
> > agreement on the proposal yet, though there are two
> > approaches have gained their voice. One is using
> > OnComplete(), another is without OnComplete(), ending
> > interceptors will be needed whenever terminal actions are
> > needed. As Eoghan has pointed out, there are cases
> > interceptor chain can be aborted in the middle of execution
> > thus the "ending interceptors" may never get chance to be
> > called - This is for HTTP 401 case. Actually I also have a
> > similar use case: when writing an interceptor that can do
> > service routing [2], I will need to call
> > InterceptorChain.abort() on my dummy service once I have
> > redirected the request to the real destination. Provided the
> > cases listed above are valid use cases, I would vote for
> > using OnComplete(), as this semantic allows for unwinding the
> > chain with onComplete() calls to the already traversed interceptors.
> > >
> > > Any thoughts? This has been on my to-do-list for a while,
> > so I will definitely be volunteering to do this work.
> > >
> > > Cheers,
> > > Jervis
> > >
> > > [1].
> > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> 702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> > [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
> >
> >
> >> -----Original Message-----
> >> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> >> Sent: 2007年3月26日 9:43
> >> To: cxf-issues@incubator.apache.org
> >> Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
> >>
> >>
> >>
> >> [
> >> https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
> >> an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
> >> 2483994 ]
> >>
> >> Dan Diephouse commented on CXF-411:
> >> -----------------------------------
> >>
> >> I think we decided that we need to get postHandleMessage
> >> removed now. Any volunteers?
> >>
> >>
> >>> Refactoring interceptor chain
> >>> -----------------------------
> >>>
> >>> Key: CXF-411
> >>> URL: https://issues.apache.org/jira/browse/CXF-411
> >>> Project: CXF
> >>> Issue Type: Task
> >>> Components: Core
> >>> Affects Versions: 2.0-RC
> >>> Reporter: unrealjiang
> >>> Assigned To: Jervis Liu
> >>> Fix For: 2.0-RC
> >>>
> >>>
> >>>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >>
> >>
> >>
>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by "Liu, Jervis" <jl...@iona.com>.
Are we suggesting that we take the "ending interceptors" approach as the replacement to subchain invocation, then we add an interceptor.onAbort() to handle the situation where interceptorChain.abort() is called but these already traversed interceptors still have some resources to close or some terminal actions to take before the chain can be gracefully shut down. I view this as a good compromise if the performance or semantic complexity is really a concern. In this case, I would suggest we don't add interceptor.onAbort() at least for the time being. as for these scenarios which we believe "ending interceptors" do not work, we do not have any valid use case to prove that we need "ending interceptors" in the first place: in-bound reading, we don't know any use case that an interceptor needs a terminal action; out-bound writing, we don't know a use case that an interceptor still need to call its terminal action when the chain is aborted. We are free to add such APIs when real requirement arrives.
.
Cheers,
Jervis
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 2007年3月27日 21:15
> To: cxf-dev@incubator.apache.org
> Cc: cxf-issues@incubator.apache.org
> Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
>
>
> I think OnComplete provides an unnecessary inefficiency semantic for
> interceptors. When an "OnComplete" exists, then the interceptor is
> forced to service it, whether it wants it or not, all the
> time. Why make
> the call? That's inefficient.
>
> These interceptors are "one-way" unlike CORBA ones, which are two-way
> (request/reply).
> So you can give the interceptors a more proactive, preemptive
> semantic
> in that the interceptor *assumes* the calls have followed
> through to the
> end, *unless* told otherwise, i.e. somebody called
> InterceptorChain.abort(). That's not an unreasonable
> assumption, and it
> avoids having to making calls to OnComplete.
>
> Perhaps an "OnAbort" is more appropriate.
>
> Cheers,
> -Polar
>
>
> Liu, Jervis wrote:
> > Have we decided to remove OnComplete()? Quickly went
> through the thread [1], it shows that we haven't reached any
> agreement on the proposal yet, though there are two
> approaches have gained their voice. One is using
> OnComplete(), another is without OnComplete(), ending
> interceptors will be needed whenever terminal actions are
> needed. As Eoghan has pointed out, there are cases
> interceptor chain can be aborted in the middle of execution
> thus the "ending interceptors" may never get chance to be
> called - This is for HTTP 401 case. Actually I also have a
> similar use case: when writing an interceptor that can do
> service routing [2], I will need to call
> InterceptorChain.abort() on my dummy service once I have
> redirected the request to the real destination. Provided the
> cases listed above are valid use cases, I would vote for
> using OnComplete(), as this semantic allows for unwinding the
> chain with onComplete() calls to the already traversed interceptors.
> >
> > Any thoughts? This has been on my to-do-list for a while,
> so I will definitely be volunteering to do this work.
> >
> > Cheers,
> > Jervis
> >
> > [1].
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>
>
>> -----Original Message-----
>> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
>> Sent: 2007年3月26日 9:43
>> To: cxf-issues@incubator.apache.org
>> Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>>
>>
>>
>> [
>> https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
>> an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
>> 2483994 ]
>>
>> Dan Diephouse commented on CXF-411:
>> -----------------------------------
>>
>> I think we decided that we need to get postHandleMessage
>> removed now. Any volunteers?
>>
>>
>>> Refactoring interceptor chain
>>> -----------------------------
>>>
>>> Key: CXF-411
>>> URL: https://issues.apache.org/jira/browse/CXF-411
>>> Project: CXF
>>> Issue Type: Task
>>> Components: Core
>>> Affects Versions: 2.0-RC
>>> Reporter: unrealjiang
>>> Assigned To: Jervis Liu
>>> Fix For: 2.0-RC
>>>
>>>
>>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
RE: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by "Liu, Jervis" <jl...@iona.com>.
Are we suggesting that we take the "ending interceptors" approach as the replacement to subchain invocation, then we add an interceptor.onAbort() to handle the situation where interceptorChain.abort() is called but these already traversed interceptors still have some resources to close or some terminal actions to take before the chain can be gracefully shut down. I view this as a good compromise if the performance or semantic complexity is really a concern. In this case, I would suggest we don't add interceptor.onAbort() at least for the time being. as for these scenarios which we believe "ending interceptors" do not work, we do not have any valid use case to prove that we need "ending interceptors" in the first place: in-bound reading, we don't know any use case that an interceptor needs a terminal action; out-bound writing, we don't know a use case that an interceptor still need to call its terminal action when the chain is aborted. We are free to add such APIs when real requirement arrives.
.
Cheers,
Jervis
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 2007年3月27日 21:15
> To: cxf-dev@incubator.apache.org
> Cc: cxf-issues@incubator.apache.org
> Subject: Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
>
>
> I think OnComplete provides an unnecessary inefficiency semantic for
> interceptors. When an "OnComplete" exists, then the interceptor is
> forced to service it, whether it wants it or not, all the
> time. Why make
> the call? That's inefficient.
>
> These interceptors are "one-way" unlike CORBA ones, which are two-way
> (request/reply).
> So you can give the interceptors a more proactive, preemptive
> semantic
> in that the interceptor *assumes* the calls have followed
> through to the
> end, *unless* told otherwise, i.e. somebody called
> InterceptorChain.abort(). That's not an unreasonable
> assumption, and it
> avoids having to making calls to OnComplete.
>
> Perhaps an "OnAbort" is more appropriate.
>
> Cheers,
> -Polar
>
>
> Liu, Jervis wrote:
> > Have we decided to remove OnComplete()? Quickly went
> through the thread [1], it shows that we haven't reached any
> agreement on the proposal yet, though there are two
> approaches have gained their voice. One is using
> OnComplete(), another is without OnComplete(), ending
> interceptors will be needed whenever terminal actions are
> needed. As Eoghan has pointed out, there are cases
> interceptor chain can be aborted in the middle of execution
> thus the "ending interceptors" may never get chance to be
> called - This is for HTTP 401 case. Actually I also have a
> similar use case: when writing an interceptor that can do
> service routing [2], I will need to call
> InterceptorChain.abort() on my dummy service once I have
> redirected the request to the real destination. Provided the
> cases listed above are valid use cases, I would vote for
> using OnComplete(), as this semantic allows for unwinding the
> chain with onComplete() calls to the already traversed interceptors.
> >
> > Any thoughts? This has been on my to-do-list for a while,
> so I will definitely be volunteering to do this work.
> >
> > Cheers,
> > Jervis
> >
> > [1].
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>
>
>> -----Original Message-----
>> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
>> Sent: 2007年3月26日 9:43
>> To: cxf-issues@incubator.apache.org
>> Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>>
>>
>>
>> [
>> https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
>> an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
>> 2483994 ]
>>
>> Dan Diephouse commented on CXF-411:
>> -----------------------------------
>>
>> I think we decided that we need to get postHandleMessage
>> removed now. Any volunteers?
>>
>>
>>> Refactoring interceptor chain
>>> -----------------------------
>>>
>>> Key: CXF-411
>>> URL: https://issues.apache.org/jira/browse/CXF-411
>>> Project: CXF
>>> Issue Type: Task
>>> Components: Core
>>> Affects Versions: 2.0-RC
>>> Reporter: unrealjiang
>>> Assigned To: Jervis Liu
>>> Fix For: 2.0-RC
>>>
>>>
>>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by Polar Humenn <ph...@iona.com>.
I think OnComplete provides an unnecessary inefficiency semantic for
interceptors. When an "OnComplete" exists, then the interceptor is
forced to service it, whether it wants it or not, all the time. Why make
the call? That's inefficient.
These interceptors are "one-way" unlike CORBA ones, which are two-way
(request/reply).
So you can give the interceptors a more proactive, preemptive semantic
in that the interceptor *assumes* the calls have followed through to the
end, *unless* told otherwise, i.e. somebody called
InterceptorChain.abort(). That's not an unreasonable assumption, and it
avoids having to making calls to OnComplete.
Perhaps an "OnAbort" is more appropriate.
Cheers,
-Polar
Liu, Jervis wrote:
> Have we decided to remove OnComplete()? Quickly went through the thread [1], it shows that we haven't reached any agreement on the proposal yet, though there are two approaches have gained their voice. One is using OnComplete(), another is without OnComplete(), ending interceptors will be needed whenever terminal actions are needed. As Eoghan has pointed out, there are cases interceptor chain can be aborted in the middle of execution thus the "ending interceptors" may never get chance to be called - This is for HTTP 401 case. Actually I also have a similar use case: when writing an interceptor that can do service routing [2], I will need to call InterceptorChain.abort() on my dummy service once I have redirected the request to the real destination. Provided the cases listed above are valid use cases, I would vote for using OnComplete(), as this semantic allows for unwinding the chain with onComplete() calls to the already traversed interceptors.
>
> Any thoughts? This has been on my to-do-list for a while, so I will definitely be volunteering to do this work.
>
> Cheers,
> Jervis
>
> [1]. http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
> [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
>
>
>> -----Original Message-----
>> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
>> Sent: 2007年3月26日 9:43
>> To: cxf-issues@incubator.apache.org
>> Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>>
>>
>>
>> [
>> https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
>> an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
>> 2483994 ]
>>
>> Dan Diephouse commented on CXF-411:
>> -----------------------------------
>>
>> I think we decided that we need to get postHandleMessage
>> removed now. Any volunteers?
>>
>>
>>> Refactoring interceptor chain
>>> -----------------------------
>>>
>>> Key: CXF-411
>>> URL: https://issues.apache.org/jira/browse/CXF-411
>>> Project: CXF
>>> Issue Type: Task
>>> Components: Core
>>> Affects Versions: 2.0-RC
>>> Reporter: unrealjiang
>>> Assigned To: Jervis Liu
>>> Fix For: 2.0-RC
>>>
>>>
>>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
RE: [jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by "Liu, Jervis" <jl...@iona.com>.
Have we decided to remove OnComplete()? Quickly went through the thread [1], it shows that we haven't reached any agreement on the proposal yet, though there are two approaches have gained their voice. One is using OnComplete(), another is without OnComplete(), ending interceptors will be needed whenever terminal actions are needed. As Eoghan has pointed out, there are cases interceptor chain can be aborted in the middle of execution thus the "ending interceptors" may never get chance to be called - This is for HTTP 401 case. Actually I also have a similar use case: when writing an interceptor that can do service routing [2], I will need to call InterceptorChain.abort() on my dummy service once I have redirected the request to the real destination. Provided the cases listed above are valid use cases, I would vote for using OnComplete(), as this semantic allows for unwinding the chain with onComplete() calls to the already traversed interceptors.
Any thoughts? This has been on my to-do-list for a while, so I will definitely be volunteering to do this work.
Cheers,
Jervis
[1]. http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200702.mbox/%3cFA1787F64A095C4090E76EBAF8B183E071FC0F@owa-emea.iona.com%3e
[2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing
> -----Original Message-----
> From: Dan Diephouse (JIRA) [mailto:jira@apache.org]
> Sent: 2007年3月26日 9:43
> To: cxf-issues@incubator.apache.org
> Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>
>
>
> [
> https://issues.apache.org/jira/browse/CXF-411?page=com.atlassi
> an.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1
> 2483994 ]
>
> Dan Diephouse commented on CXF-411:
> -----------------------------------
>
> I think we decided that we need to get postHandleMessage
> removed now. Any volunteers?
>
> > Refactoring interceptor chain
> > -----------------------------
> >
> > Key: CXF-411
> > URL: https://issues.apache.org/jira/browse/CXF-411
> > Project: CXF
> > Issue Type: Task
> > Components: Core
> > Affects Versions: 2.0-RC
> > Reporter: unrealjiang
> > Assigned To: Jervis Liu
> > Fix For: 2.0-RC
> >
> >
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (CXF-411) Refactoring interceptor chain
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483994 ]
Dan Diephouse commented on CXF-411:
-----------------------------------
I think we decided that we need to get postHandleMessage removed now. Any volunteers?
> Refactoring interceptor chain
> -----------------------------
>
> Key: CXF-411
> URL: https://issues.apache.org/jira/browse/CXF-411
> Project: CXF
> Issue Type: Task
> Components: Core
> Affects Versions: 2.0-RC
> Reporter: unrealjiang
> Assigned To: Jervis Liu
> Fix For: 2.0-RC
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-411) Refactoring interceptor chain
Posted by "Bozhong Lin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bozhong Lin updated CXF-411:
----------------------------
Fix Version/s: 2.0-RC
Assignee: Jervis Liu
> Refactoring interceptor chain
> -----------------------------
>
> Key: CXF-411
> URL: https://issues.apache.org/jira/browse/CXF-411
> Project: CXF
> Issue Type: Task
> Components: Core
> Affects Versions: 2.0-RC
> Reporter: unrealjiang
> Assigned To: Jervis Liu
> Fix For: 2.0-RC
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-411) Refactoring interceptor chain
Posted by "Jervis Liu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jervis Liu closed CXF-411.
--------------------------
> Refactoring interceptor chain
> -----------------------------
>
> Key: CXF-411
> URL: https://issues.apache.org/jira/browse/CXF-411
> Project: CXF
> Issue Type: Task
> Components: Core
> Affects Versions: 2.0-RC
> Reporter: unrealjiang
> Assigned To: Jervis Liu
> Fix For: 2.0-RC
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.