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

[Rod Widdowson]

> Isn't it still the case that the code gets one shot at building the gauges? It's going to just omit them from the system if the
initial service
> load fails, right?

I don't think so. The gauge creating won't fail because the service doesn't even have to exist at that point.  The gauges are
created in the constructor and at that stage the service isn't even set - I found that out the hard way when I tried to put the test
there.

The service is only consulted when the gauge is consulted by calling get Value, and at that stage the map is created on the fly.
But the key is that it is consulted on *every* call to getValue().   If the service hasn't instantiated for the first call it will
still be asked at the next call.  Once I had internalized this I realized quite how cute the ReloadableServiceGaugeSet is.  Mind you
the double nested injected classes that I introduced for the Metadata gauge are a bit funky.

So :
- If you call a gauge.getValue() before the service is running you'll get silence (which I don't log - after all the fact that it
hasn't been initialized will be obvious from the service level gauges).

- Any time after the service starts running a call to gauge.getValue() will return results.

- If you call a gauge.getValue() and it has been injected with the "wrong type" you'll get a warning - but as discussed you have
deeper troubles when that happens

- If someone injects their own Attribute Resolver into the service (allowable but hugely unlikely) then they'll get a debug message
because we cannot interrogate the data connector state.  Easily fixable with a new interface but why bother until someone asks.


Rod