Return-Path: Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org Received: (qmail 72739 invoked from network); 23 Jan 2007 09:06:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Jan 2007 09:06:14 -0000 Received: (qmail 72226 invoked by uid 500); 23 Jan 2007 09:06:20 -0000 Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org Received: (qmail 72211 invoked by uid 500); 23 Jan 2007 09:06:20 -0000 Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cxf-dev@incubator.apache.org Delivered-To: mailing list cxf-dev@incubator.apache.org Received: (qmail 72202 invoked by uid 99); 23 Jan 2007 09:06:20 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2007 01:06:20 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jliu@iona.com designates 65.223.216.181 as permitted sender) Received: from [65.223.216.181] (HELO amereast-smg1.iona.com) (65.223.216.181) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2007 01:06:11 -0800 Received: from amer-ems1.IONAGLOBAL.COM ([10.65.6.25]) by amereast-smg1.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0N93sun005560 for ; Tue, 23 Jan 2007 04:03:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73ECD.AA032DF9" Subject: RE: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF? Date: Tue, 23 Jan 2007 04:05:44 -0500 Message-ID: <9A4696F35B459043970EE4A85A3173900665B7@amer-ems1.IONAGLOBAL.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should we close the handlers in CXF? Thread-Index: Acc+Rx0lfpUIo0/nQTC2llHZBBG2uQAfHN/4 References: <9A4696F35B459043970EE4A85A3173900665B3@amer-ems1.IONAGLOBAL.COM> <7b774c950701220902i83985f6x7ac9041e034711f4@mail.gmail.com> From: "Liu, Jervis" To: , X-Virus-Checked: Checked by ClamAV on apache.org ------_=_NextPart_001_01C73ECD.AA032DF9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ________________________________ 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.=20 Subsequent actions depend on whether the MEP in use requires a response = to the message currently=20 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,=20 and the runtime invokes handleFault on the next handler or dispatches = the message (see=20 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=20 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=20 processed or not:=20 Response: Normal message processing stops, close is called on each = previously invoked handler in=20 the chain, the message direction is reversed, and the exception is = dispatched (see section 9.1.2.3).=20 No response: Normal message processing stops, close is called on each = previously invoked handler=20 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.=20 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? =20 > 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/%3= cFA1787F64A095C4090E76EBAF8B183E071FADE@emea-ems1.dublin.emea.iona.com%3e= = =20 > > -- Dan Diephouse Envoi Solutions http://envoisolutions.com = | = http://netzooid.com/blog = =20 ------_=_NextPart_001_01C73ECD.AA032DF9--