Thoughts on configuring action-based timer reporting

[Cantor, Scott]

Started looking at ways to inject configurable timer reporting into the IdP AbstractProfileAction base class, and it occurs to me we could drive this pretty effectively with a child context.

Instead of having to inject all kinds of configuration state about what to measure, we could have an early flow action conditionally attach a child context to the tree that would be checked by the base class in the Pre/Post-execute hooks and tell it when to start and stop particular named timers.

That way the overhead for the "off" case is just a check for an absent child context, and otherwise it would know to check to see if it should start or stop a timer based on the identity of the profile action class.

Could even be driven with a scriptlet to attach the child context with the right content to measure whatever people happen to be interested in.

-- Scott