[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128441#comment-16128441
]
Carsten Ziegeler commented on SLING-7043:
-----------------------------------------
The problem is obvious with the current commons scheduler implementation :)
The "stable package version" is only true for as long as the client code is not
using some dropwizard API directly. As soon as it does so, you're back to
square one. And we encourage people to do so (by the adapter pattern) and even
worse require it (through the MetricRegistry).
In addition, if the dropwizard API changes in an incompatible way, it might
even get worse - as the client code might use a different version (say 3.3) as
the commons metrics implementation (e.g. 3.2). Then the whole thing breaks
nevertheless.
In the long run I don't think that we should move forward with #A - I would
rather like to see us to go with #B - and if problems with dropwizard arise,
solve them where they were introduced; but not try to workaround and create
confusing API usage.
> 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)
