cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <>
Subject RE: [jira] Commented: (CXF-411) Refactoring interceptor chain
Date Tue, 27 Mar 2007 16:36:19 GMT
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.


> -----Original Message-----
> From: Polar Humenn []
> Sent: 2007年3月27日 21:15
> To:
> Cc:
> 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]. 
> [2]:
>> -----Original Message-----
>> From: Dan Diephouse (JIRA) []
>> Sent: 2007年3月26日 9:43
>> To:
>> Subject: [jira] Commented: (CXF-411) Refactoring interceptor chain
>>     [ 
>> 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:
>>>             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.

View raw message