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: domain of polar.humenn@iona.com
 designates 65.223.216.181 as permitted sender)
Message-ID: <45D0B3B8.1060406@iona.com>
Date: Mon, 12 Feb 2007 13:36:40 -0500
From: Polar Humenn <phumenn@iona.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: Proposal for chaning CXF Interceptor APIs. WAS: RE: When should
 we close the handlers in CXF?
References: <9A4696F35B459043970EE4A85A31739006682A@amer-ems1.IONAGLOBAL.COM>
 <7b774c950702120702r1bf96f17l45a9b2aa5251be19@mail.gmail.com>
In-Reply-To: <7b774c950702120702r1bf96f17l45a9b2aa5251be19@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dan, Jervis,

Comments in line.

Dan Diephouse wrote:
> On 2/12/07, Liu, Jervis <jliu@iona.com> wrote:
>>
>>
>>
>> > -----Original Message-----
>> > From: Polar Humenn [mailto:phumenn@iona.com]
>> > Sent: Friday, February 09, 2007 1:11 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?
>> >
>> >
>> > Okay, I'm going to reply to my own message, because after a coffee I
>> > have come to some nirvana about this issue.
>> >
>> > The reason you want an onFinish() call is to address the subchain
>> > problem.  In one of the emails below it is stated:
>> >
>> >        A. MessageSenderInterceptor:  call conduit.close(message) after
>> >     the complete chain    has been traversed.
>> >
>> >
>> > I presume that you want A.handleMessage() to be called to do
>> > some things
>> > (like install more interceptors) and then after everything
>> > has been done
>> > to the message, you want A.onFinish() called to call
>> > conduit.close(message).
>> >
>> > My basic question is, why isn't the conduit.close(message)
>> > called in a
>> > separate interceptor's handleMessage() call?
>> >
>> Actually, I have thought about this option as well. For every 
>> interceptor
>> that needs a terminal action, we will need a pair of interceptors. For
>> example, the SoapOutInterceptor will be SoapOutStartInterceptor and
>> SoapOutEndInterceptor, SoapOutStartInterceptor writes the start 
>> element of
>> SOAP Body and Envelope, while SoapOutEndInterceptor writes the end 
>> element
>> of SOAP Body and Envelope. Same thing applies to conduit.close(message),
>> we will need a MessageSenderEndInterceptor to call 
>> conduit.close(message)
>> (or any other interceptors that is appropriate). This definitely 
>> works, and
>> this can achieve exact same execution path as we can do with 
>> onComplete(),
>> it just occurs to me that there are too many interceptors we have to 
>> write
>> ;-)
>>
>>
> Agreed. It could be done via another interceptor, but its a common enough
> case that we'd like to make it simpler.
> On a related note I would like to see the method named onTermination() -
> this would imply "on termination of the chain take this action..." which
> would give interceptors a chance to close resources associated with the
> message. I'm -1 on the current "postHandleMessage" method name.
>
I would argue that you may make some of the "common" cases "simpler" to 
a degree in the sense that both operations will be in the same class, 
but it make the semantics much more complex in general, and less efficient:

     1. Many interceptors will have to implement onTermination() without 
a need for it.
     2. It will get always get called.

The only advantage of this approach is that interceptors may be able to 
save some instance state between the two calls, like a reference to an 
object. However, that can be done merely by two subclasses implementing 
the interceptor interface inside a single class.

Also, it complicates the fault handing, which hasn't yet been addressed.

For instance, what happens if a Fault is thrown in onTermination()?
    Does it unwind through handleFault()?
    If so, in what direction?
    How many times? Once or twice? If possibly twice, which first call 
to handleFault called?
    Does it unwind through the interceptor's handleFault() operation 
twice? On what run was it when it did? 

I surmise that the current interceptor interface {handleMessage, 
handleFault) is adequate, and it was the doIntercept() and 
doInterceptInSubChain() calls that kind of mucked up the cleanliness and 
simplicity of the approach.

Given that the proposal includes the eliminatation doIntercept() and 
doInterceptInSubChain() you are going to have to the same amount of work 
to current interceptors that use doIntercept and doInterceptInSubChain:

You will have to split the single handleMessage() that into a "save 
state on the message" so that handleMessage and onTermination() may 
communicate properly. However, this is the same amount of work you need 
to do to create two separate interceptors using handleMessage calls.

Also, for example. let's say you require functionality that needs to be 
interleaved between the handleMessage and onTermination() calls of one 
interceptor (call it A). You will need two interceptors B and C as you 
will not be able to get by with one. For example, interceptor B will 
have a potent handleMessage() that goes AFTER interceptor A, and limp 
onTermination() call. Inteceptor C must get installed BEFORE interceptor 
A with a limp handleMessage() and a potent onTermination() call. I say 
installing interceptor C before interceptor A is a counter intuitive 
approach.

A simple linear installation of interceptors is clearer, more efficient, 
and has simple already defined fault handling.

Cheers,
-Polar


Cheers,
-Polar