> > 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. PRE_LOGICAL). > We could have > inAfter/inBefore/outAfter/outBefore/inPhase/outPhase, Or just add a (boolean outbound) parameter to each of the existing methods. > 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 way? ... 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. /Eoghan
