[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125291#comment-16125291 ]
Carsten Ziegeler commented on SLING-7043: ----------------------------------------- Let me ask this differently: when or why should code use Sling's commons metrics? I see no point in doing so, even the strange API of MetricsServiceFactory is more awkward than using MetricRegistry directly. If it would be a complete abstraction I can see a reason for doing so - but as it's not like that at all, I'm wondering what our guidance to users is? I see the point of completely disabling metrics - if this is a real problem at all - and in that case I think a contribution to Dropwizard will solve that > Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction > -------------------------------------------------------------------------- > > Key: SLING-7043 > URL: https://issues.apache.org/jira/browse/SLING-7043 > Project: Sling > Issue Type: Bug > Affects Versions: Commons Metrics 1.0.0 > Reporter: Carsten Ziegeler > Priority: Blocker > Fix For: commons metrics 1.2.4 > > > commons metrics provides a nice abstraction over com.codahale.metrics - > however it is exporting com.codahale.metrics.MetricRegistry which seems to > be the only way to get at registered metrics objects. Which in turn is > completely breaking the purpose of this bundle. > So we should > a) drop exporting that service and avoid leaking internal implementation > details > b) create our own version of the registry service -- This message was sent by Atlassian JIRA (v6.4.14#64029)