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 James.Mao@iona.com designates
 65.223.216.181 as permitted sender)
Message-ID: <4583673E.2030509@iona.com>
Date: Sat, 16 Dec 2006 11:25:50 +0800
From: James Mao <james.mao@iona.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: isGET in interceptors...
References: <7b774c950611291103y68c2fa70qe05c88d2865d5e71@mail.gmail.com>
	 <45738BDA.6000202@iona.com>
	 <7b774c950612041146u332877c9l6953ef7ea1dfc472@mail.gmail.com>
	 <45751A0A.50104@iona.com>
	 <7b774c950612051927r61d5bd2en7b5c08fce5d0c625@mail.gmail.com>
	 <b23ecedc0612060121s59d3118ai4fc40a7c32a5415@mail.gmail.com>
	 <4576A814.8030904@iona.com>
	 <b23ecedc0612060702j7b4a57c5y9c30dbe14efc2ddd@mail.gmail.com>
	 <4577882E.2050901@iona.com>
	 <7b774c950612150633h91b82aal2a4da6f60065f8c2@mail.gmail.com>
 <b23ecedc0612150721h160812b8xd8e867f35827bdc6@mail.gmail.com>
In-Reply-To: <b23ecedc0612150721h160812b8xd8e867f35827bdc6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Nodet,
> I'm not quite sure that there is a need to change the chain
> dynamically at all.  

I don't like the idea neither, and it's the last solution i would like 
to try. (And i think DanD also agreed on it)
> Why not considering a tree instead of
> a simple list ?  
> Depending on some conditions (HTTP VERB,
> operation QName, ...), a branch of the tree would be used.
> I guess this may need a bit of design, but would allow a clean
> separation of interceptors between, while allowing a static
> interceptor chain.

I think you are right, it's could be tree, and it's not just for HTTP 
verb, in some cases we need to dispatch the message in different route.
for example,  CXF-147 <http://issues.apache.org/jira/browse/CXF-147> the 
mixed bare/wrapped style can be benefit from this approach. and also 
CXF-35 <http://issues.apache.org/jira/browse/CXF-35> Support multiple 
services/bindings on the same endpoint 
<http://issues.apache.org/jira/browse/CXF-35>

I think maybe we should have something call connectors, and the 
connectors basically have two interfaces one for the IN interceptor, and 
one for OUT interceptor(s), and we can use connectors to chain the 
interceptors, so it's the connector to decide which way/exit to go 
depending on the message it accepted from the IN interceptor(just like a 
switch). but i'm not sure will that works? as you said we need a bit of 
design.

current chain is getting more and more complex, we even have sub chain 
concept now, it's getting debug more and more difficult. to be honest i 
don't like. maybe we should think more about this.

Cheers,
James.
> As I said in a previous mail, I don't really see how policies can
> be applied on a per operation level without allowing different
> interceptor chain (or all interceptors would have to check if
> they should be applied, which is the current case with the GET
> problem).
> Would it be too complex ? Or there is no real use case for that ?
>
> On 12/15/06, Dan Diephouse <dan@envoisolutions.com> wrote:
>> On 12/7/06, James Mao <james.mao@iona.com> wrote:
>> >
>> >
>> > I'm OK with the changing the chain dynamically, they both works. if we
>> > change the chain dynamically, then for both the SOAP binding and XML
>> > binding and any other binding to filter the interceptors 
>> dynamically, i
>> > mean the maintenance cost is same. but this approach do have a 
>> benefit,
>> > the benefit is that all the isGET logic in the same place, if we 
>> want to
>> > add some configuration for this function, it'll be more easier. But 
>> the
>> > other side is, it'll be harder to change the chain if the 
>> interceptor is
>> > coarse-grained, that means we want some part of the logic of the
>> > inteceptor, but in some conditions we want to exclude the 
>> interceptors,
>> > but yes, you can break down the interceptors into pieces to work 
>> around
>> > the problem. So there's pros and cons.
>>
>>
>> Can you please justify the performance benefit of this if we go down 
>> this
>> route? As noted in the previous email if we have a dynamic interceptor
>> removal, than we still have problems if a user adds an interceptor 
>> and they
>> aren't aware they need to look for the isGET case.
>>
>> I think we should synthesize a document, and unless you can provide some
>> compelling performance reason I don't see any reason not too. You 
>> haven't
>> shown anything to back up your reasoning that there is a performance 
>> issue.
>>
>> - Dan
>>
>>
>> -- 
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>>
>
>