Hi Dan, Jervis,
Comments in line.
Dan Diephouse wrote:
On 2/12/07, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: Polar Humenn [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 09, 2007 1:11 AM
> To: [email protected]
> 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
