Thoughts on configuring action-based timer reporting

[Cantor, Scott]

On 9/21/16, 4:07 PM, "dev on behalf of Tom Zeller" <dev-bounces at shibboleth.net on behalf of tzeller at dragonacea.biz> wrote:

> Just a comment wondering if there should be an activation condition
> for the "off" case, maybe per metric or action ? dunno

All the conditional logic can go into populating the context, so that should be sufficient without adding another dimension.

@Nonnull @NonnullElements private final Map<String,Map<String,String>> startMap;
@Nonnull @NonnullElements private final Map<String,Map<String,String>> stopMap;

Map of profile ID to "thing" to Timer name.

What's not appearing to work so well is the Timer itself, haven't worked out exactly how they work yet or if you can start in one object and stop in another. I might have to actually store off something in the context, but that's another reason to use a context for it.

This isn't actually specific to actions either. We could instrument obvious things like the attribute resolver or data connectors directly of course, but it would be possible to trigger it conditionally by profile this way.

If we have a convention for different objects to determine the value to attach the timer name to, you could have it map a profile to a connector ID to a timer.

Any object that has a natural start/stop point would just call start/stop on the child context to trigger a lookup for whether there's a timer installed to start or stop.

Trying to be as low-impact as possible to the objects being timed, otherwise the code gets ugly really fast.

-- Scott