Do we need DisabledMonitorSource?

[GoogleCodeExporter]

As of now this class is merely mentioned in SimonServletFilter - but filter has 
already options how to disable monitoring there. Is there any other application 
of DisabledMonitorSource?

Also - it returns null everywhere, it should better return disabled/null simons 
(if possible with generic nature of the class).

Original issue reported on code.google.com by virgo47 on 30 Apr 2013 at 11:25

[GoogleCodeExporter]

The stuff done in various StopwatchSource implementations (Http, Spring, 
Ejb...) can be expensive from performance point view. Far more expensive than 
what's done in Simon manager.

The rationale behind DisabledMonitorSource is to disable monitoring at a higher 
level and be a generic solution which can be used in all kinds of interceptors. 
It's the same as DisabledManager but at a higher level.

When the MonitorSource returns null, it means "Don't monitor here", look at  
StopwatchTemplate which should be used in all interceptors. I can not return a 
valid Stopwatch because it would mean converting the interception point into a 
stopwatch, and again this is something expensive and useless since the we don't 
want to use it in the end.

Original comment by gerald.q...@gmail.com on 30 Apr 2013 at 2:33

[GoogleCodeExporter]

OK, let's say we need it for our users. :-)

Check StopwatchTemplate, I changed it that it returns disabled Split. This 
should be minimal overhead but you have non-null object. What do you think 
about that?

Original comment by virgo47 on 30 Apr 2013 at 2:46

[GoogleCodeExporter]

DisabledMonitorSource is there to stay. Actually DisabledStopwatchSource was 
added as well - during the merge of StopwatchTemplate with 
AbstractStopwatchSource hierarchy.

Original comment by virgo47 on 10 Jun 2013 at 9:41

• Changed state: WontFix