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 gnodet@gmail.com designates
 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=UfcSOQZerwAkilYsKMSqbhZ2wCLc1H0tDzABggHjGs/loS0MrB0xA2azCwkxKIXsjG1P5X21j0hdqUTsMFSCKyhpGUT1tNEerZTtsmKPM07nUrG0WlNTHKf259Slx85LSgTkwgnBVGnQg6dXJhUF9L/tXzTDP/ugJbzAn8LKNss=
Message-ID: <b23ecedc0612150721h160812b8xd8e867f35827bdc6@mail.gmail.com>
Date: Fri, 15 Dec 2006 16:21:38 +0100
From: "Guillaume Nodet" <gnodet@gmail.com>
To: cxf-dev@incubator.apache.org
Subject: Re: isGET in interceptors...
In-Reply-To: <7b774c950612150633h91b82aal2a4da6f60065f8c2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

I'm not quite sure that there is a need to change the chain
dynamically at all.  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.
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
>
>


-- 
Cheers,
Guillaume Nodet