cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Interceptor Ordering
Date Wed, 01 Nov 2006 18:02:13 GMT
Glynn, Eoghan wrote:
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
>> Sent: 31 October 2006 20:57
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Interceptor Ordering
>>
>> Whats wrong with having both an inbound and outbound RM interceptor? 
>> Just the extra configuration?
>>     
>
> The issue, as I understand it, is the complexity involved in arranging
> for the separate In and Out interceptors to share common state.
>
>   
I don't think its that complex. Just grab an object from the exchange:

StateHolder holder = exchange.get(StateHolder.class);
> This complexity obviously goes away if a single interceptor type is used
> for both the inbound and outbound directions, so the resulting code is
> simpler.
>
> Also, this happens to be the model followed by JAX-WS Handlers ... no
> need to repeat the arguments I've made several times in the past that
> the CXF interceptor model shouldn't gratuitously diverge from the JAX-WS
> Handler model.
>   
>> I'm not real keen on changing the interceptor semantics. I 
>> kind of prefer the In & Out interceptor approach.
>>     
>
> Can you expand on your preference for the In/Out model? What specific
> advantages do you see it bringing to the table?
>
>   
The interceptor model as it is allows interceptors to position 
themselves correctly inside the interceptor chain. (for the axis2'ers 
listening in, this is one of the parts I like about axis2...) So I can 
develop my own extensions and they can just drop in. The user doesn't 
need to know where to put them. Now as soon as you start mixing in and 
out interceptors you have problems ordering as there are different 
phases on each side and different interceptors that you care about. We 
could have inAfter/inBefore/outAfter/outBefore/inPhase/outPhase, but I 
don't like making that part of the semantics as not all messaging 
pipelines are in/out. By baking In/out semantics in you're immediately 
going to request/response type semantics in my mind.

- Dan

--

Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


Mime
View raw message