[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125296#comment-16125296
]
Chetan Mehrotra commented on SLING-7043:
----------------------------------------
Again trying to highlight what was discussed earlier also. Dropwizard api went
through some non compatible changes between 3.0 and 3.1 [1] which was
considered as one of the basis to have our own abstraction to shield against
such changes given Metrics usage was to be done in core parts of the Sling and
avoiding dependency on a third party api was a good thing to do (at least I
understood it that way).
Hence all this abstraction and recommended for code to use Sling Metrics if
they are all concerned with reporting Metrics data. If they need more Metrics
api then they are free to bind directly to Metrics api and lookup
MetricRegistry from the service registry.
So it serves both purpose given that code make the call to decide which api to
use.
bq. 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
At least I considered that because we intend to use it in some core part and
would always prefer a kill switch if it causes issues.
[1] http://markmail.org/thread/47fd5psel2wv2y42
> 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)
