Use of Metrics in the lower layers

[Cantor, Scott]

Starting to look at some foundational instrumentation work [1] and some of the obviously interesting things to measure are in OpenSAML.

I can get pretty far focusing on the higher level problems for now, but we'll have to decide how to handle instrumenting the other classes.

Depending on the type of meter involved and whether the class being instrumented needs to create the meter or just access it, there are different types of objects that might need to be injected. But the main issue is just how much we care about a compile time dependency on the instrumentation library in OpenSAML, and in parallel whether there's an efficiency concern in having to execute conditionals to tell whether to use it.

With logging, the facades like slf4j are all architected to be the neutral API, and to have efficient behavior when no logging is done, though I'm not sure how that's done, seems like there's got to still be methods getting called that wouldn't be any worse than calling our own methods or conditional checks (if (meter != null)).

Obviously the big difference is there's no portable API here and we're certainly going to build one.

I don't think "just use it in the IdP" will fly very easily, though I guess if we pushed it we could come up with our own hooking mechanisms or of course there's AOP or method proxies and other such ugliness if a dependency is really objectionable.

For now I'll stick with the IdP but I'll put the dependency management in the main parent POM.

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/DEV/IdPMetricsDetails