On 10/26/17 1:55 PM, Apekshit Sharma wrote:
bq. .....integration with metrics-library1 to support the metrics platform
for their $business1. $business2 might want to use metrics-library2....
Makes sense Josh.
bq. One final concern, bundling our "default" DropwizardMetrics 3-based
implementation could cause headaches for users who want to build their own
metrics-api implementation.
Right. Do you have something in mind to avoid this?
I think the current separation of default implementation and interfaces
as separate modules is the ideal solution.
Thanks Josh!
So the only remaining thing is, we should either
- remove this (
https://github.com/apache/hbase/blob/master/hbase-metrics-api/src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java#L67)
which seems unnecessary because Service Provider will pick up
"MetricRegistriesImpl" if it's there.
Well, the concern would be failing intuitively if the classpath is
missing any implementation at all (unlikely, but possible).
- Or move MetricRegistriesImpl in the same module as 'default'
implementation. (until we have multiple implementation)
Ahh, yeah, that's not a poor idea. Took me a moment to realize there was
both MetricRegistryImpl and MetricRegistriesImpl. I don't yet grok why
MetricRegistries is important -- I assume the ref-counting being done
there is important.
