Overriding the getValues is actually what I did for another metric. Because JMX returns
Map<InetAddress, Float> and it is impossible to come up with a general enough
interpretation of the metric for arbitrary maps.
For Lists it seems pretty obvious to me, but you are right, that if user do that by
mistake it may be misleading.
jk
----- Original Message -----
From: "Thomas Segismont" <tsegismo(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Friday, May 24, 2013 1:51:51 PM
Subject: Re: Metric interpretation of Lists returned by JMX
Hi Jiri,
I can't see a risk of regression, but I wonder how misleading it could
be if a user _incidentally_ binds a numeric metric to a List bean property.
I know we already have some kind of magic in MBeanResourceComponent for
traits bound to Array bean properties, but what about overriding
getValues in StorageServiceComponent?
Cheers
Le 24/05/2013 13:25, Jiri Kremser a écrit :
> Hi,
> sometimes JMX attributes/operations return non-primitive types, like
> List, Map, etc. Cassandra plugin needs to interpret one metric as a
> size of the list that gets returned. I've added [1] this piece of code
> to the jmx plugin to make it a general feature of the jmx plugin. It is
> not in the master branch yet (only in the cassandra branch).
>
> If you see any risks in it, please respond.
>
> [1]
https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=17cbff1dc
>
>
> jk
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel