[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125306#comment-16125306
]
Chetan Mehrotra commented on SLING-7043:
----------------------------------------
bq. but again it is totally flawed as we expose a way to get to the underlying
implementation as an API contract. This gives a false sense of safety.
Well I disagree here. It depends on the client code what it wants to use. If
the client only binds to Commons Metrics api then it gets the required support
of the abstraction (and possibly some extra features like JMX Domain name,
future support for metadata etc). If the code needs more features (which in
general does not happen, at least based on usage we have in Oak side which
follows similar pattern) then it binds to Metrics 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)
