[rhetorical] Should AttributeResolver implement the Resolver interface ?

[Cantor, Scott]

On 11/5/13, 5:32 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:

>This came up today with Rod, I thought that it did, that
>AttributeResolver implemented Resolver, but it doesn't, I guess
>because the AttributeResolver predates Resolver.
>
>If it did, if the AttributeResolver implemented the Resolver
>interface, it might make sense.

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.

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.

> Maybe the thing that handles Spring
>configuration reloading, our Service interface, could be generic in
>that it reloads Resolvers. Obviously not all components needing
>configuration reloading are currently Resolvers. I wonder if the
>AttributeFilter could be massaged into implementing Resolver somehow,
>just for the purpose of config reload.

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

-- Scott