[rhetorical] Should AttributeResolver implement the Resolver interface ?

[Tom Zeller]

>> 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).

Right, I was hung up on "Resolver".

In brief, I am thinking :

interface ReloadableService<T extends ServiceableComponent>
 start()
 stop()
 reload()
 ...
 T getServiceableComponent()

where I said "Resolver" but was thinking "ServiceableComponent", just
not all the way yet, and that still is wrong.

AttributeResolver and AttributeFilter could then implement the
ServiceComponent interface.

More of this is probably as incorrect as what I already said, but I
think a ServiceRegistry could map between

 AttributeResolver =
ServiceRegistry.getServiceComponent("shibboleth.AttributeResolver")

and

<ServiceRegistry id="shibboleth.ServiceRegistry " >
  <Service id="shibboleth.AttributeResolver"
    class="net.shibboleth.idp.service.DefaultService"
    serviceableComponent="net.shibboleth.idp.attribute.resolver.impl.DefaultAttributeResolver"
>
    <ConfigResource resource="conf/attribute-resolver.xml" ... >
  </Service>

or similar.

Not that it would help much, but then we would not need
AttributeResolverService and AttributeFilterService classes.