AttributeResolver and Resolver API

Tom Zeller tzeller at dragonacea.biz
Sat Dec 7 14:55:57 EST 2013


>> So I'm still
>> not sure it makes any sense. Just wanted to note it.
>
> Agreed. Also noting that the ResolverPlugin might be a natural fit to
> extend Resolver.

I guess, I am still confused about the semantics of "resolver".

Being sensitive to spending too much time on this, my intent here is
to clarify my understanding of our terminology rather than any coding
decision.

Before yesterday's dev call, my criteria for accepting that
AttributeResolver does not extend Resolver is time, meaning, the use
of "resolver" may have meant different things at different times in
the development cycle. Kind of like a knot in a clear piece of wood,
character.

But on yesterday's dev call, the notion of a resolver as a "searcher"
made me feel better. It took a while for the mud to settle in my mind
afterwards, but I believe we were saying that a resolver searches
through its cache of data. To me, that sounds like a "static
resolver", which performs a lookup.

An AttributeResolver, on the other hand, we said, I think, produces
attributes as a result of exercising its configuration. And that was
the distinguishing factor. (I may be getting this wrong, I know.)

This morning though, it seems to me that the core plugin to an
AttributeResolver is the DataConnector, for which the most primary
seem LDAP and RDBMS, which themselves perform searches and queries.
And DataConnector extends ResolverPlugin, which I've already said
seems like a fit for Resolver.

So I am left thinking an AttributeResolver fits our criteria for a
"dynamic resolver" which performs searches, in contrast to a "static
resolver" which performs lookups.

Anyway, it is just a naming convention and as far as I can tell has no
impact on use, so thanks for letting me take time to clarify my
understanding of our use of "resolver".

My thinking on this is probably tainted by my thinking that Resolver
methods would be appropriate for provisioning via an
AttributeResolver, since sometimes you may want to resolve one
attribute value or maybe 100k. Otherwise, I don't think we expose the
concept of multi-valued vs single-valued attributes in
attribute-resolver.xml.


More information about the dev mailing list