> -----Original Message----- > From: Polar Humenn [mailto:[EMAIL PROTECTED] > Sent: 10 April 2007 15:50 > To: [email protected] > Subject: Re: http-(conduit|destination) cfg > > > Without much investigation, I suspect the problem probably > rests with the implementation of the List type, which ever > one Spring is using.
The Spring injection into java.util.List is fine as far as I can see. A quick scan of the PhaseInterceptor code suggests the the reversal occurs in the insertInterceptor() method. See my earlier mail for more detail on this and a suggested fix. > I've seen list implementations where the add() operation, > true to LISP form, actually adds the item to the beginning of > the list. java.util.List.add() is required to be an append. In any case, I don't think the prob is in the List impl per se. > 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. Agreed on good docco, everything configurable, and clear precedence rules. Now all we need is a volunteer to pick up some of the work :) Cheers, Eoghan > 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]. > >>> > >> > >
