Endpoint resolution

[Cantor, Scott]

On 2/20/14, 7:21 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Just noting for my own (and anyone else's) edification that a couple of
>things implied by the BindingDescriptor design are that:
>
>1) you can inject different List<BindingDescriptor> instances  to
>different components/flows to get different behavior for different use
>cases
>and/or
>2) a descriptor list can contain more than one BindingDescriptor for a
>given binding URI, presumably with a different activation predicate
>
>I think having the multiplicity and flexibility of that sounds good.

I hadn't considered the second point, but I think that's true, unless I
injected them into a map somewhere, but the only use so far would be in
the endpoint population action.

Of course, you can always compose compound predicates anyway, so you're
just doing the same thing that an OR would.

>Btw, were you thinking that the actual MessageEncoder beans would be
>defined in this file also, or elsewhere?  Maybe makes sense to keep them
>together to avoid getting out-of-sync.  In the testbed I had them (really
>the sole one) defined in abstract-sso-beans.xml,
> but that was really just because there wasn't another logical place at
>the time.

I hadn't thought about it, but I'm not sure I want to keep these in "user"
space anyway, I just did that for the initial draft. I'd rather the
encoders not be in the user-editable files, I think that's just
boilerplate for 99.9% of users, and that's not what we want to be showing
people.

But I suspect these binding lists are also going to be essentially left
alone also, just like they were in handler.xml today, so moving them into
system/ and putting the encoders into the file makes sense.

They also won't change much if at all across releases, so anybody needing
to mess with them is probably safe doing so.

-- Scott