cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
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


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

---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog





Mime
View raw message