> - I don't see a reason to have NoopMetric and MetricsService.NOOP in the API.
In Oak I have found it useful to have NOOP in API for code to evolve. Some examples 1. Allow use of Metrics in code Sling bundle - If we add a direct dependency on Metrics then any bundle if to be deployed on older setup would also pull in metrics bundle and Metrics library. Having NOOP would allow such bundles to have a optional dependency on MetricsService and default to NOOP (which can be easily inlined and reimported) and let them be usable in older setups 2. It also enables unit testing - One can stub out the MetricsService using NOOP implementation to test the logic without pulling in complete implementation > what happens if a creation method on the MetricsService for the same name is > called twice? The service is thread safe and same object would be reused. So yes it can hide duplicates. One idea I had was to use a ServiceFactory and detect such duplicates there based on calling bundle > what about an api to get all metrics or a specific one? The focus for wrapper API was collection side as that would be used by majority of classes. For getting all Metrics one can directly access the underlying MetricRegistry by using dropwizard Metrics library API Chetan Mehrotra On Wed, Jan 6, 2016 at 9:10 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > Lgtm, thanks Chetan, so +1 :) > > Some comments: > > - I don't see a reason to have NoopMetric and MetricsService.NOOP in the > API. > - what happens if a creation method on the MetricsService for the same > name is called twice? > - what about an api to get all metrics or a specific one? > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
