[
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)
