cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unreal Jiang <sinbad_...@yahoo.com>
Subject Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Date Wed, 07 Feb 2007 09:56:01 GMT
LogicalHandlerInterceptor already has a onCompletion() method to do some cleanup work. Maybe
we can use it as the cleanup method name.

Unreal

Dan Diephouse <dan@envoisolutions.com> 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:dan@envoisolutions.com]
> Sent: Tue 1/23/2007 1:02 AM
> To: cxf-dev@incubator.apache.org
> 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/%3cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e
> >
> >
> --
> 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.
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message