[
https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125544#comment-16125544
]
Carsten Ziegeler commented on SLING-7043:
-----------------------------------------
I think we have two options:
a) we add missing functionality to Sling's api like a registry and clients like
the scheduler can use Sling's API only for their use cases. In addition, we
should also deprecate/remove access to the underlying implementation, namely
removing the adapter pattern and getting com.codahale.metrics.MetricRegistry as
a service. With this we would fulfill the original goal of an independent API
without any strange leakage of the underlying implementation API.
or
b) we acknowledge that dropwizard will always be the base for our
implementation and see the Sling bundle as an OSGi service based extension to
it (things like registering a Gauge through the whiteboard etc.). In this case
we should probably deprecate/drop all the wrapping stuff from the API (I
haven't looked in detail, but I guess we can drop all API). This allows for
using the dropwizard API in an OSGi service based fashion and we would still
have some of our exptensions like JMX support.
Both approaches are valid and imho provide a viable solution; but right now we
have 50% of a) and 50% of b) - and that's where I'm having a problem with.
> 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)
