> -----Original Message-----
> From: Polar Humenn [mailto:[EMAIL PROTECTED]
> Sent: 09 April 2007 14:54
> To: [email protected]
> Subject: Re: http-(conduit|destination) cfg
>
> Is saying "it's undefined" really good enough for things that
> are "intuitive"? I mean, saying "division by zero" is
> undefined because there is some formal reason for doing so.
>
> I can see your point that if the order of specified
> interceptors are governed by their internal Before/After
> settings that the config file would conflict with the
> ordering of the "list". So, if the "config"
> doesn't really define the order of the interceptors and it is
> desired that be the case, then perhaps we should be using a
> construct that does
> *not* imply an ordering such as Collection of List?
The behavior I've seen is that for two configured interceptors, the
order they appear in the list injected into the InterceptorProvider (the
Bus impl in your case) is actually the *same* as order in which the
interceptors are enumerated in the config file. I don't know if this is
*guaranteed* though, as the underlying schema type is an xsd:sequence
with unbounded maxOccurs. Dunno if this schema type actually implies an
ordering.
Note that the ordering-connoting List type is actually only directly
associated with the programmatic representation of the individual
interceptor chains, not with the schema type in config (although of
course the one is injected into the other).
Also note that the individual (ordered) interceptor lists maintained by
the various interceptor providers (Bus, Binding, Endpoint, Service,
Client) need to be merged into a single chain. In addition, the chain is
separated into phases and the getBefore/After ordering constraints
honoured.
So the initial orderings of the individual "partial" interceptor lists
does not necessarily reflect the order of the full chain constructed
from these lists, i.e. the order in which the interceptors are
traversed. This is the crux of the issue.
On an aside, I noticed slightly some slightly questionable logic in
PhaseInterceptorChain.insertInterceptor(). If two interceptors are being
inserted into the *same* phase, with *no* intra-interceptor ordering
asserted (i.e. empty getBefore/After()) then the first interceptor is
appended to the sub-list for that phase, whereas the second is inserted
in position zero i.e. is *prepended* to the sub-list. This probably
explains the ordering reversal you observed. And it would be easy to
fix.
If you're worried about it, just add something like:
if (before.size() == 0 && after.size() == 0) {
intercs.add(interc);
return;
}
just before the for loop in PhaseInterceptorChain.insertInterceptor().
And of course validate with a full test run, just in case some other
code is implicitly dependent on the current behavior.
/Eoghan
> Cheers,
> -Polar
>
> Dan Diephouse wrote:
> > On 4/5/07, Polar Humenn <[EMAIL PROTECTED]> wrote:
> >
> >> And furthermore, I was surprised (by trial and error, mind
> you) that
> >> if you list two interceptors in a SpringBus bean interceptor
> >> property, that they get installed in the reverse order
> than the order listed!
> >>
> >>
> > Ordering for interceptors is not currently defined unless
> you set the
> > before/after properties on your interceptor.
> > Regards,
> > - Dan
> >
>
>
