cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Interceptor Ordering
Date Thu, 02 Nov 2006 10:45:01 GMT
> > 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.

Surely the "where to put the interceptor in the chain" question is
encoded within the interceptor itself in *both* models, in the
PhaseInterceptor getPhase() and getBefore/getAfter()?

I don't see how this would be any different for separate In/Out
interceptors as opposed to a single consolidated interceptor.

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

Sure, but a single consolidated interceptor instance would still have to
be added separately to the each of the relevant In/Out/Fault chains ...
i.e. I'm not argueing that we should consolidate the chains also, just
that we should allow for a consolidated interceptor implementations. 

Such a consolidated interceptor would also generally only only make
sense for a phase that's common to both the in & out flows (e.g.

> We could have 
> inAfter/inBefore/outAfter/outBefore/inPhase/outPhase, 

Or just add a (boolean outbound) parameter to each of the existing

> but I 
> don't like making that part of the semantics as not all 
> messaging pipelines are in/out.

In that case, the Interceptor.handleMessage() call can simply reduce to
a no-op.

> By baking In/out semantics in 
> you're immediately going to request/response type semantics 
> in my mind.

But surely both models bake in the in/out semantics, just in a different

... i.e. the in/out semantics are baked in either as separate
interceptor implementations for the in and out directions, or a single
consolidated interceptor implementation that acts differently depending
on whether the direction is inbound or outbound.


View raw message