[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128281#comment-16128281
]
Chetan Mehrotra commented on SLING-7043:
----------------------------------------
I still do not think that current status is having a problem (but that can be
just me!). As said earlier. Client code can bind to
# Sling Commons Metrics API - Get some added benefits and stable package
version. Majority of code needs would be fullfilled by this api
# Dropwizzard Metrics API - Get access MetricRegistry and access to actual
metrics value
Note that Dropwizzard binds package export to release version and some of the
exported interfaces are Consumer type. So if code in Sling uses that we need to
update such bundles when upgrading Metrics bundle (SLING-7047).
Even if we go for option #A above we would still need to export the
MetricRegistry as services as quite a bit of existing reporters provided by
Metrics itself work with that service. It does not make sense to wrap all such
reporters. So access to MetricRegistry by reporter should be fine
> 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)
