LogicalHandlerInterceptor already has a onCompletion() method to do some cleanup work. Maybe we can use it as the cleanup method name.
Unreal Dan Diephouse <[EMAIL PROTECTED]> wrote: Could I offer just once suggestion? Could we rename the postHandleMessage to onFinish(Message) or onComplete(Message)? - Dan On 2/6/07, Unreal Jiang wrote: > > Hi, > > Looks like there has no opponent for jervis' proposal, I will create a > jira task for this proposal and sign it me. > > Cheers > Unreal > > "Liu, Jervis" wrote: > > ________________________________ > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: Tue 1/23/2007 1:02 AM > To: [email protected] > Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When > should we close the handlers in CXF? > > > > On 1/22/07, Liu, Jervis wrote: > > > > Hi, I would like to summarize what we have been discussed in this thread > > (including Eoghan's proposal posted last Oct [1]) regarding Interceptor > API > > changes. Any comments would be appreciated. > > > > Currently our Interceptor APIs look like below: > > > > public interface Interceptor { > > void handleMessage(T message) throws Fault; > > void handleFault(T message); > > } > > > > Also in the interceptor chain, we have a notion of sub-chain or > > interceptor chain reentrance by calling message.getInterceptorChain > ().doIntercept(message) > > or message.getInterceptorChain().doInterceptInSubChain(message). > > > > The main issues we have with the current implementation are: > > > > 1. Fault handling. See Eoghag's email [1] > > > > 2. Sub-chain reentrance. See previous discussion in this thread. > > > > We propose to change Interceptor API as below: > > > > public interface Interceptor { > > void handleMessage(T message) throws Fault; > > void handleFault(T message); > > void close(T message); > > } > > > > handleFault(T message) method is used to process fault message (which is > > done by handleMessage() in fault-chain currently). > > > > I'm not sure I understand how you want to use this. I guess I could see > two > > ways > > > 1. Remove In/OutFault interceptors and call handleFault on the In/Out > > interceptors. I don't know that mapping works especially well though. > > 2. Don't call handleFault on in/out interceptors, but only on the > > in/outFault interceptors - this would mean, for example, that the logic > from > > Soap11OutFaultInterceptor would be moved from the handleMessage to > > handleFault. > > > Can you be more specific about what you mean? > > > Sorry, after rethinking about this, I've changed my mind slightly, so here > is the idea: > > CXF Interceptor API will be similiar to JAX-WS API, section 9.3.2.1. > > Throw ProtocolException or a subclass This indicates that normal message > processing should cease. > Subsequent actions depend on whether the MEP in use requires a response to > the message currently > being processed or not: > > Response: Normal message processing stops, fault message processing > starts. The message direction > is reversed, if the message is not already a fault message then it is > replaced with a fault message4, > and the runtime invokes handleFault on the next handler or dispatches the > message (see > section 9.1.2.2) if there are no further handlers. > > No response: Normal message processing stops, close is called on each > previously invoked handler > in the chain, the exception is dispatched (see section 9.1.2.3). > > > Throw any other runtime exception This indicates that normal message > processing should cease. Subse- > quent actions depend on whether the MEP in use includes a response to the > message currently being > processed or not: > > Response: Normal message processing stops, close is called on each > previously invoked handler in > the chain, the message direction is reversed, and the exception is > dispatched (see section 9.1.2.3). > > > No response: Normal message processing stops, close is called on each > previously invoked handler > in the chain, the exception is dispatched (see section 9.1.2.3). > > However, the difference is CXF interceptors are not designed to hook in > user logic as these JAX-WS handlers do, thus handleFault is not needed > in CXF interceptors (correct me if I am wrong, but I believe this is > the purpose that JAX-WS handlers's handleFault method designed for. I.e, > when > a known exception - ProtocolException occurs, handleFault() gives handler > developer a hook to clean up sth, for example, roll back a transaction, > this is different from what close() is supposed to do. The latter is > designed to clean things up under a succeeded situation). For any Runtime > exceptions thrown by interceptors, we just wrap it as soap exception then > dispatch it back calling handleMessage. > > So here is the change we need to make: > > 1. Add a postHandleMessage() into Interceptor interface > > 2. Remove handleFault() method from Interceptor interface. Or we can > still keep it for a while until we are absolutely sure we wont need > this method, but I presume there is nothing we need to do in this method. > > 3. We will NOT add a close() method into Interceptor interface, as > CXF interceptors are stateless, there is no resources need to be closed. > > public interface Interceptor { > void handleMessage(T message) throws Fault; > void postHandleMessage(T message); > } > > When an interceptor chain ends normally, we need to call > postHandleMessage() on each previously traversed interceptor in a reversed > direction. > > When a fault occurs on the in-bound chain, an exception will be thrown > from the interceptor, after catching the exception in > PhaseInterceptorChain, we unwind the current chain by calling > postHandleMessage() on each previously traversed interceptor and then jump > to the out-fault-chain, calling handleMessage() on each interceptor with > the fault message. > > Any thoughs? > > > > > > close(T message) method is called on a reverse direction at the end of > > interceptor chain or when a fault or exception occurs. Take the fault > > handling case as an example, below is how handleFault and close work > > together > > > > +1 to close() - Although I think Eoghan has a good point about the > ordering > > not necessarily being the same. I think we need to do a little bit more > > digging before we can know whether or not sub chains can be removed. > > > when a fault occurs on the in-chain, we unwind the current chain by > calling > > close() on each previously traversed interceptor and then jump to the > > out-fault-chain, calling handleFault() on each interceptor with the > fault > > message. > > > > Close method is also used to remove the sub-chain reentrance. See the > > SOAPHandlerInterceptor example I posted previously. > > > > Cheers, > > Jervis > > > > [1] > > > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200611.mbox/[EMAIL > PROTECTED] > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog > > > > > > --------------------------------- > Access over 1 million songs - Yahoo! Music Unlimited. -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog --------------------------------- 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut.
