> -----Original Message-----
> From: Fred Dushin [mailto:[EMAIL PROTECTED]
> Sent: 10 April 2007 13:44
> To: [email protected]
> Subject: Re: http-(conduit|destination) cfg
>
> Hm. I don't see it that way.
>
> Each list is really "chunked" into phases, no?
Well, not really, at least the way its currently implemented.
The phase separation only occurs when a full interceptor chain is being
assembled from the constituent sub-lists. This is done afresh for each
invocation.
So the ordering of each sub-list only says something about the ordering
of contained interceptors of *the same phase*.
To fall-back on some half-remembered math terminology, there's a
*partial order* defined over the list, not a *total order*.
> So what does
> it mean to specify an ordering declaratively, when the
> declared ordering is not what will actually be realized at runtime?
My understanding is that the partial order defined declaratively (or
programmatically in the injected lists are subsequently manipulated by
the application) is like a fallback position ... this is the order of
interceptors of the same phase if not overridden by the
getBefore/After().
However, I see where you're going with the "this may not be the most
user-friendly thing in the world" thought.
One useful improvement might be to allow the getBefore/After constraints
to be specified declaratively also.
So for example it may be confusing if the ordering implied by:
<bean id="phaseA_interceptor1" class="phaseA.Interceptor1"/>
<bean id="phaseA_interceptor2" class="phaseA.Interceptor2"/>
<bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
<property name="inInterceptors">
<list>
<ref bean="phaseA_interceptor1"/>
<ref bean="phaseA_interceptor2"/>
</list>
</property>
</bean>
is then overridden programmatically by phaseA.Interceptor2.getAfter()
returning "phaseA.Interceptor1", thereby reversing the ordering implied
by the config.
Obviously clearer if the getAfter() constraint could be specified in
config also, e.g.:
<bean id="phaseA_interceptor2" class="phaseA.Interceptor2">
<after>
<set>
<ref bean="phaseA_interceptor1"/>
<set>
</after>
</bean>
> It's misleading at best -- an outright lie, at worst.
Maybe we just need to be clearer about the *partial* ordering aspect, so
that nothing is inferred ordering-wise from something like:
<bean id="phaseA_interceptor" class="phaseA.Interceptor"/>
<bean id="phaseB_interceptor" class="phaseB.Interceptor"/>
<bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
<property name="inInterceptors">
<list>
<ref bean="phaseA_interceptor"/>
<ref bean="phaseB_interceptor"/>
</list>
</property>
</bean>
i.e. it's only the relative ordering of phases A and B that important
here.
But again, it might be clearer if the phase could also be specified
declaratively, so a human reader of the config wouldn't have to look up
the code to see what's passed to setPhase(). Something like:
<bean id="MyInterceptor" class="impl.MyInterceptor">
<phase>A</phase>
</bean>
> Not sure I suggested a change to a programmatic API, unless
> that was a logical consequence of something I said elsewhere.
Somewhere on the thread it was suggested we replace List with some
unordered Collection type, by Polar probably. But yeah, cool, so we're
agreed the API stays the same.
> Was just suggesting that we change/deprecate the name of a
> config varaible, and to put it on a long finger, at that.
Deprecating the config variable would be a bit awkward as several demos
and system tests depend on it to engage functionality like WS-RM and
WS-A. But definitely +1 to a clearer explanation of the subtlety in the
docco. And the above config enhancements might be useful if someone
wants to pick them up (I don't have the bandwidth).
Cheers,
Eoghan
> -Fred
>
> On Apr 10, 2007, at 6:41 AM, Glynn, Eoghan wrote:
>
> > It's a bit more subtle that, I think. The individual
> interceptor lists
> > associated with each interceptor provider are indeed ordered, so the
> > list type is appropriate [IMO].
>
>
