[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265249#comment-16265249 ] Carsten Ziegeler commented on SLING-7043: - [~chetanm] Sure, although I have the feeling that we will move this forever > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265185#comment-16265185 ] Chetan Mehrotra commented on SLING-7043: [~cziegeler] Would it be fine to move this to next release and unblock current one? I would like to cut a release for few issues fixed so far but would not have bandwidth for addressing this issue in near future (post discussing the approaches!) > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128281#comment-16128281 ] Chetan Mehrotra commented on SLING-7043: I still do not think that current status is having a problem (but that can be just me!). As said earlier. Client code can bind to # Sling Commons Metrics API - Get some added benefits and stable package version. Majority of code needs would be fullfilled by this api # Dropwizzard Metrics API - Get access MetricRegistry and access to actual metrics value Note that Dropwizzard binds package export to release version and some of the exported interfaces are Consumer type. So if code in Sling uses that we need to update such bundles when upgrading Metrics bundle (SLING-7047). Even if we go for option #A above we would still need to export the MetricRegistry as services as quite a bit of existing reporters provided by Metrics itself work with that service. It does not make sense to wrap all such reporters. So access to MetricRegistry by reporter should be fine > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125420#comment-16125420 ] Bertrand Delacretaz commented on SLING-7043: I think this discussion should move to our dev list - you guys don't seem to have consensus and it looks like changes would have impact on backwards compatibility. > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125315#comment-16125315 ] Chetan Mehrotra commented on SLING-7043: Technically there is NOOP Metrics support also. So we have 2 implementations. > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125302#comment-16125302 ] Carsten Ziegeler commented on SLING-7043: - I understand the "intend" of our own abstraction - 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. Either we have a full abstraction making it safe to use - or we don't need the abstraction. But this is now something in the middle saying "yeah we have this abstraction, but you can directly use the dropwizard api as well" - and not even that for some use cases you have to use the dropwizard api as commons scheduler shows > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125291#comment-16125291 ] Carsten Ziegeler commented on SLING-7043: - Let me ask this differently: when or why should code use Sling's commons metrics? I see no point in doing so, even the strange API of MetricsServiceFactory is more awkward than using MetricRegistry directly. If it would be a complete abstraction I can see a reason for doing so - but as it's not like that at all, I'm wondering what our guidance to users is? 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 > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125268#comment-16125268 ] Chetan Mehrotra commented on SLING-7043: bq. it's now depending on two APIs (Slings metrics and Dropwizard). Okie. So far in none of other places the code had to depend on MetricRegistry. If the code want to use that then yes it need not go over abstraction provided by Common Metrics. We discussed all this when metrics abstraction was introduced (see DL threads referred in SLING-4080). If you think most code need to use MetricRegistry also then its fine to drop Commons Metrics > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125266#comment-16125266 ] Carsten Ziegeler commented on SLING-7043: - Let's look at a client of the metrics library: commons scheduler - it's now depending on two APIs (Slings metrics and Dropwizard). It can be easily rewritten to be just depending on Dropwizard, so why are we mixing APIs there? > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125258#comment-16125258 ] Chetan Mehrotra commented on SLING-7043: bq. Gauge does not seem to be implemented at all. Guage support was added with SLING-5966 > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125257#comment-16125257 ] Carsten Ziegeler commented on SLING-7043: - I think the idea of a stable interface is now totally flawed, as soon as code is using the MetricRegistry - which is public/documented api of the Sling Metrics API - it has the same problem as if it would be using Dropwizard metric directly. And I just noticed that we even support the adapter pattern which means the Sling Metrics API is directly tied to the Dropwizard API and not independent or more stable at all. For most of the provided metric types it seems we're only providing wrappers, Gauge does not seem to be implemented at all. So in general I think this feels all a little bit strange and is not really what is pretending to be. I'm strongly in favour of contributing whatever extensing we have back to Dropwizard so we can drop this library completely - maybe we have to keep the OSGi service implementation (not interface) and the web console support - but we should not have additional 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125238#comment-16125238 ] Chetan Mehrotra commented on SLING-7043: As mentioned in [1] the Metrics support has 2 users # Code which want to collect metric data for some activity- They are primarily concerned with just reporting about stuff happening # Code which want to process collected metrics data like Metric Reporter In any setup there would be lot more #1 compared to #2. Purpose of Sling Metrics api was to provide a stable interface for #1 so that # any incompatible change in dropwizard metric does not effect the majority of users (i.e. #1) # If metrics collection lead to some overhead we can disable it completely. Its not possible with Dropwizard metric # Possibility to support some custom extension like timeseries support in future The MetricReports are closely tied to metric api so its fine to directly use it and need not introduce any abstraction there. [1] https://sling.apache.org/documentation/bundles/metrics.html#requirement-of-wrapper-interfaces > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123346#comment-16123346 ] Carsten Ziegeler commented on SLING-7043: - Why do we have the then sling commons metrics at all? > 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)
[jira] [Commented] (SLING-7043) Exporting com.codahale.metrics.MetricRegistry is breaking the abstraction
[ https://issues.apache.org/jira/browse/SLING-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123220#comment-16123220 ] Chetan Mehrotra commented on SLING-7043: Export of MetricRegistry is required for other reporters to work (which are codehale specific) like those from [~ianeboston] at [1]. Normal Sling code in general should not require the access to reported values and should mostly be doing report [1] https://github.com/ieb/statsd-reporter-osgi > 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)
