cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: [jira] Commented: (CXF-411) Refactoring interceptor chain
Date Tue, 27 Mar 2007 17:14:43 GMT
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 <jliu@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message