non Fast-fail, LDAP and the testbed.. And Guages.

[Cantor, Scott]

> Or is there some implied ordering which would be broken (for instance the Logging Service might a still be initializing
> while we start the Attribute Resolver Service.

That's the risk I guess. Hard to say, but it is generally true that most of the services don't actually depend on each other that way, they use each other via slots in context objects (like how you can pass metadata services into the filter via the filter context.

> I can see the motivation - if someone does manage to configure and attribute filter service as the attribute resolver
> service then the guage code will quietly sit doing nothing about it specialism (it won't have a class cast issue because we
> are safe against that).  But quite frankly that is probably the least of the issues that the deployers will have at this point.

I don't think I made conscious decisions to implement it that way, it just ended up behaving like that and I never saw a clean way to do it. If there's some way to manage that I can live with whatever...

> But I am still wondering whether the tests are too draconian?  In my case if I allowed null (but still failed against non null
> of the wrong type) allows the testbed to start. 

If you mean the tests in the metrics code, probably. I think the problem was that the way I did it, the objects in the metric layer can't get constructed if the service isn't there. Maybe some façade is needed, or perhaps with Java 8 we can slide in use of Optional?

-- Scott