Without much investigation, I suspect the problem probably rests with
the implementation of the List type, which ever one Spring is using.
I've seen list implementations where the add() operation, true to LISP
form, actually adds the item to the beginning of the list. So, if Spring
is chugging down the list in order the list actually comes out backwards.
I'm all for getting the Spring to configure the interceptors completely,
if at all, phase, Before, After. sure. However, still must be some good
documentation on what is happening, especially when the implementation
of the interceptors may say something else (which overrides what?) and
what is happening *should* intuitively follow the config file.
In any case, for now, it's good enough to say that *if* the interceptors
are in the same phase and they don't have any or the same before/after
constraints, that they appear in the order they are listed (from top to
bottom, left to right) in the config file.
We just have to ensure the order, regardless of the List implementation
being used.
Otherwise, we can stop the use of generic Spring beans, and make a type
schema for the Bus, Endpoint, etc.
Cheers,
-Polar
Glynn, Eoghan wrote:
-----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].
