[jira] [Comment Edited] (SLING-5420) Add support for MetricOptions to better control certain optional features

["Chetan Mehrotra (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091471#comment-15091471 ] 

Chetan Mehrotra edited comment on SLING-5420 at 1/11/16 5:53 AM:
-----------------------------------------------------------------

[initial patch|^SLING-5420-v1.patch] for the same. It introduces a new immutable class {{MetricOptions}} which can be passed with each type of metric creation method. Here one can set various options. 

*Usage*
For default i.e. no customization

{code:java}
Meter meter = service.meter("test", MetricOptions.DEFAULT);
{code}

When some customization is to be done
{code:java}
MetricOptions opts = MetricOptions.builder()
       .description("Determines request rate")
       .build();
Meter meter = service.meter("requests", opts);
{code}

* Provides a builder to create the option instance
* One can use {{MetricOptions.DEFAULT}} for default

*Points to thought about*
# Should we create overloaded methods for each metric which takes option. This would allow use single arg method to create default. While overloaded methods can be used for passing the options
# Currently same type of option instance is defined for all types of metric. In future it might be possible that we need specific option type say for {{Histogram}} to select the [Resorvoir|https://dropwizard.github.io/metrics/3.1.0/manual/core/#exponentially-decaying-reservoirs] type. I think such cases would be very few
## For such case either we just use same {{MetricOption}} and do some validation based on metric type later. Call out in javadoc which option is specific to the type
## Or have metric type specific option with a base option which capture common option

[~bdelacretaz] [~cziegeler] Need some feedback and guidance!. Objective here is to ensure that API does not require non compatible change and can be evolved gradually wrt features added later. And still keep things simple and not over engineer here for some future feature!


was (Author: chetanm):
[initial patch|^SLING-5420-v1.patch] for the same. It introduces a new immutable class {{MetricOptions}} which can be passed with each type of metric creation method. Here one can set various options. 

*Usage*
For default i.e. no customization

{code:java}
Meter meter = service.meter("test", MetricOptions.DEFAULT);
{code}

When some customization is to be done
{code:java}
MetricOptions opts = MetricOptions.builder()
       .description("Determines request rate")
       .build();
Meter meter = service.meter("requests", opts);
{code}

* Provides a builder to create the option instance
* One can use {{MetricOptions.DEFAULT}} for default

*Points to thought about*
# Should we create overloaded methods for each metric which takes option. This would allow use single arg method to create default. While overloaded methods can be used for passing the options
# Currently same type of option instance is defined for all types of metric. In future it might be possible that we need specific option type say for {{Histogram}} to select the [Resorvoir|https://dropwizard.github.io/metrics/3.1.0/manual/core/#exponentially-decaying-reservoirs] type. I think such cases would be very few
## For such case either we just use same {{MetricOption}} and do some validation based on metric type later. Call out in javadoc which option is specific to the type
## Or have metric type specific option with a base option which capture common option

[~bdelacretaz] [~cziegeler] Need some feedback and guidance!. Objective here is to ensure that API does not require non compatible change and can be evolved gradually wrt features added later

> Add support for MetricOptions to better control certain optional features
> -------------------------------------------------------------------------
>
>                 Key: SLING-5420
>                 URL: https://issues.apache.org/jira/browse/SLING-5420
>             Project: Sling
>          Issue Type: Task
>          Components: Commons
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>             Fix For: Commons Metrics 1.0.0
>
>         Attachments: SLING-5420-v1.patch
>
>
> For certain usecases (SLING-5418, SLING-5419) we need to configure some more options as part of creating a given metric instance.
> To allow for such features (and other possible extension in future) it would be better to also accept a {{MetricOption}} as part of create call. This can be used to capture info like description, time series requirement etc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)