[rhetorical] Should AttributeResolver implement the Resolver interface ?

[Rod Widdowson]

> I don't pretend to have much experience with the interface, the first time
> I did one was the SessionResolver. That worked ok, but I don't think the
> AttributeResolver fits the paradigm well because it operates on a fairly
> boundless set of criteria. Resolvers seem to need a pretty constrained set
> of Criterion types.


Yea, my instinct when Tom raised it was that this was a completely different
type of resolution.  

> I think about the only way you could handle this with AttributeResolver is
> to have a ProfileRequestContext Criterion that literally tunnelled in the
> entire context, which seems like a cheat. If it created some kind of
> advantage to do that, I guess you could.

I independently came up with the same idea this morning while walking the
dogs (as you do) and also came to the conclusion that that would be pretty
much forcing the design to use it.

> I don't think it makes sense to insist that every reloadable Service be a
> Resolver, that seems like a different, orthogonal abstraction.

That’s my instinct too.   If we need a service abtraction, it’s a different
thing (and quite probably contained within the IdP).

FYI (and to derail the thread slightly) I *am* making progress on the
"service" question (what is it? why do we need it? Why doesn't spring do it
for us? What did V2 do and why?) but it is a bit of a morass and I am
currently deep in literature survey ("A week in the lab will always save you
an afternoon in the library").  Rolling this is ourselves pretty trivial,
but if Spring will do it for us there seems little reason to duplicate the
effort.   

If anyone can point me to documentations or implementations that allow
partial reload without restarting the container I'd be grateful.  This seems
like such an obvious thing that I feel certain that Spring supports it and
that I'm missing something.

I *am* aware of refreshable beans
(http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/dyn
amic-language.html#dynamic-language-refreshable-beans) but have yet to grock
where the tie in to dynamic language comes and also of
AbstractRefreshableApplicationContexts (which have to be implicated).