cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Rationalizing the InterceptorProviders....
Date Fri, 06 Jun 2008 17:37:47 GMT

On Jun 6, 2008, at 12:53 PM, Dan Diephouse wrote:

> 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.

The other option is to make in and out symetrical.   Example:

Server in: bus, service, endpoint, binding
Server out:  binding, endpoint, service, bus

That said, I don't really like it as I think it overly complicates  
things and is then more to document.  I think I'll try the two I  
listed below and see which performs the best and go with it.

> 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.

Hmm...  good point about adding to Server.   I'll have to think about  
that a bit more and double check that we even have the Server in all  
three cases.   (example: right now on the client side, we don't have  
the client when setting up the fault chain.   I need to address that.)


> Dan
> On Fri, Jun 6, 2008 at 9:38 AM, Daniel Kulp <> 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
> -- 
> Dan Diephouse
> |

Daniel Kulp

View raw message