Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <813d89dc0806060953n5d24dc98ga65d7faeee1497d8@mail.gmail.com>
Date: Fri, 6 Jun 2008 09:53:09 -0700
From: "Dan Diephouse" <dan.diephouse@mulesource.com>
To: dev@cxf.apache.org
Subject: Re: Rationalizing the InterceptorProviders....
In-Reply-To: <93D97541-BF56-4739-B2A3-72D86B954DCB@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_8246_15012384.1212771189197"
References: <93D97541-BF56-4739-B2A3-72D86B954DCB@apache.org>

------=_Part_8246_15012384.1212771189197
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm with ya on the need for consistency here. I honestly have no idea which
one will perform best, but I think either options is reasonable.

I'll throw one more thing out - we could possibly make Server an
InterceptorProvider if we wanted a mirror to the Client InterceptorProvider.
I'm not sure if that gives us any needed functionality, but it might make it
possible to remove the need for Service to be an InterceptorProvider.

Dan

On Fri, Jun 6, 2008 at 9:38 AM, Daniel Kulp <dkulp@apache.org> wrote:

>
> I'm trying to dig into CXF-1547 to try and get the "proper" fix in place.
>   Basically, I'm trying to make sure all the InterceptorProviders are
> properly examined and in a consistent order.    We basically have 5
> interceptor providers:
>
> Endpoint
> Binding
> Service
> Bus
> Client  (client side only)
>
>
> On the server side, they are evaluated in this order:
> In:  bus, endpoint, binding, service
> Out: endpoint, service, bus, binding
> Fault: endpoint, binding, service, bus
>
> On the client side:
> In: bus, endpoint, client, binding
> Out: bus, endpoint, client, binding
> Fault: endpoint, binding, service, bus
>
>
> Things to note:
> Client side doesn't look at the Service at all except for faults. We
> definitely need to fix that.
> Server side uses different ordering for all three chains.
>
>
> I'd like to make this completely consistent.   I want to make it:
>
> Server:   bus, binding, endpoint, service
> Client:    bus, binding, endpoint, service, client
>
> Or:
> Server: bus, service, endpoint, binding
> Client: bus, client, service, endpoint, binding
>
>
> Any opinions or objections?    Looking through things, I'm leaning toward
> the second option.   It LOOKS like the binding seems to define the most
> "addAfter" interceptors which cause more work when building the
> InterceptorChain if they are already in the chain.   Thus, putting them at
> the end may perform the best.   I may run some checks to make sure though.
>
> In anycase, any thoughts?
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>


-- 
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

------=_Part_8246_15012384.1212771189197--