[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125257#comment-16125257
]
Carsten Ziegeler commented on SLING-7043:
-----------------------------------------
I think the idea of a stable interface is now totally flawed, as soon as code
is using the MetricRegistry - which is public/documented api of the Sling
Metrics API - it has the same problem as if it would be using Dropwizard metric
directly. And I just noticed that we even support the adapter pattern which
means the Sling Metrics API is directly tied to the Dropwizard API and not
independent or more stable at all.
For most of the provided metric types it seems we're only providing wrappers,
Gauge does not seem to be implemented at all.
So in general I think this feels all a little bit strange and is not really
what is pretending to be.
I'm strongly in favour of contributing whatever extensing we have back to
Dropwizard so we can drop this library completely - maybe we have to keep the
OSGi service implementation (not interface) and the web console support - but
we should not have additional API
> 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)
