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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] [2]: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing > -----Original Message----- > From: Dan Diephouse (JIRA) [mailto:[EMAIL PROTECTED] > Sent: 2007年3月26日 9:43 > To: [email protected] > 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
