[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125238#comment-16125238
]
Chetan Mehrotra commented on SLING-7043:
----------------------------------------
As mentioned in [1] the Metrics support has 2 users
# Code which want to collect metric data for some activity- They are primarily
concerned with just reporting about stuff happening
# Code which want to process collected metrics data like Metric Reporter
In any setup there would be lot more #1 compared to #2. Purpose of Sling
Metrics api was to provide a stable interface for #1 so that
# any incompatible change in dropwizard metric does not effect the majority of
users (i.e. #1)
# If metrics collection lead to some overhead we can disable it completely. Its
not possible with Dropwizard metric
# Possibility to support some custom extension like timeseries support in future
The MetricReports are closely tied to metric api so its fine to directly use it
and need not introduce any abstraction there.
[1]
https://sling.apache.org/documentation/bundles/metrics.html#requirement-of-wrapper-interfaces
> 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)
