[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125312#comment-16125312
]
Carsten Ziegeler commented on SLING-7043:
-----------------------------------------
The Resource API provides an abstraction over multiple implementations unifying
client code - so that's a different situation. If you're client code adapts to
a JCR object, you know that it might not work with each and every resource
provider. In contrast, if your client code adapts to a dropwizard class, this
can be assumed to always work. And this makes the adapter pattern in the
metrics case questionable as well - there are not multiple implementations and
you might be able to do different adaptions. Each object provides exactly one
adaption and we explicitely state that. It's like saying every Resource adapts
to Node (or Property).
> 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)
