[
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)
