cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF?
Date Wed, 07 Feb 2007 07:00:41 GMT
Hi Polar, comments in-line.

Cheers,
Jervis

> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 2007?2?7? 6:05
> To: cxf-dev@incubator.apache.org
> Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: 
> RE: When should we close the handlers in CXF?
> 
> 
> I'm still trying to find out how this interceptor stuff works. So 
> forgive me if I seem naive. :-[
> 
> You say CXF interceptors are stateless. Are you saying that 
> "statelessness" is a requirement to be a CXF interceptor? Or are you 
> saying that the processing interceptors that are currently 
> used in CXF 
> are stateless and that's all that need to be supported?
> 
> I can definitely see a use case for CXF interceptors 
> maintaining state.
> 
> A simple one is an outbound message counter. The interceptor 
> increments 
> a counter on handleMessage() assuming the message makes out 
> the end (has 
> no way of knowing). So the interceptor must decrement its counter on 
> handleFault() because that tells the interceptor that the 
> message never 
> made it out the end because of some interceptor downstream in 
> the chain.
> 
Once interceptors are created (eg, in SoapBindingFactory.java), their instances are shared
across all interceptor chains and threads. Interceptors have to be stateless for the sake
of thread safe. If you really have to have some states that you want to be shared among interceptors,
you can put them into Message. 


> So, if I have this right, what you are proposing is to alter the 
> semantics, and only call this onFinish() method on the unwind 
> chain when 
> the message makes finally makes it out the end of the chain.
> 
> This changes the semantics quite a bit. With the handleFault approach 
> one can assume that the message will be successful in negotiating the 
> chain *unless* it is told otherwise, (handleFault), which leads to 
> optimistic processing. The latter onFinish() approach requires me to 
> *wait* to see *if* the message was successful, which is a 
> pessimistic, 
> possibly more expensive approach.
> 
> It seems to me, that "fault" processing is the exceptional 
> case, and one 
> should be able to assume optimistic processing, unless told otherwise.
> 

Actually what has been proposed does not change the semantics a lot. We only want to do two
changes:

1. Remove handlerFault(). The reason for this has been presented in the previous discussion,
just quoted again below: "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."

2. Add a onFinish(Message) or onComplete(Message) method (using name DanD suggested): this
method is called in a reversed direction when chain completes, can be used to remove the sub-chain
or interceptor re-entrance. For example, SoapOutInterceptor can use onComplete to write the
end element of SoapBody SoapEnvelop, this way SoapOutInterceptor does not need to wrap its
following interceptors in a sub chain.



> Thoughts?
> 
> The other thing I don't get, is what constitutes an Inbound Fault 
> Message as opposed to an Inbound Message? Why does this make a 
> difference in Interceptors of inbound and outbound messages?
> 
> Cheers,
> -Polar
> 
> 
> Dan Diephouse 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 <sinbad_jia@yahoo.com> 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" <jliu@iona.com> 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/200
611.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.
>
>
>
>


Mime
View raw message