Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=4wfOO8cTwj7I/spI0vQP3mPId33bn4RPA/tkrAbui/Pw/b8mYAOsx+HO7uJ+pTVOP44qLv9OxZo8yWYfT72El58EWplV5+QFbzMjbd3wdX2M7L8U0T0/GiZqwdkT6OXbDStsAJljXhQVI26MW8Uesi+sEWMJlnR0HzSjs+wefqI=;
Date: Mon, 5 Feb 2007 22:42:14 -0800 (PST)
From: Unreal Jiang <sinbad_jia@yahoo.com>
Subject: RE: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should
 we close the handlers in CXF?
To: cxf-dev@incubator.apache.org
In-Reply-To: <9A4696F35B459043970EE4A85A3173900665B7@amer-ems1.IONAGLOBAL.COM>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1077692110-1170744134=:44557"
Content-Transfer-Encoding: 8bit
Message-ID: <250928.44557.qm@web32613.mail.mud.yahoo.com>

--0-1077692110-1170744134=:44557
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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/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.
--0-1077692110-1170744134=:44557--