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 Mon, 26 Mar 2007 18:03:09 GMT
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 <jliu@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 <jliu@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

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