You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the spec, the annotated naming conventions section in the second table (for annotations on a class) states that the metric name uses information (the package or canonical class name) of the declaring class, meaning the class which declares the method.
The TCK includes AbstractTimedBean with a class-level @Timed annotation and a timedMethod method. ConcreteExtendedTimedBean extends AbstractTimedBean and adds anotherTimedMethod.
The TCK's ConcreteExtendedTimedBeanTest#callTimedMethodOnce test method invokes timedMethod and makes sure the timer's count changes by 1. But interestingly to look up the timer to check the timer's count that test uses the subclass name. From the spec would we expect the test to look up the timer for the timedMethod method using the superclass name which is the declaring class of the method being invoked?
Existing implementations of the spec pass the TCK but they and the TCK seem in conflict with the spec here.
The text was updated successfully, but these errors were encountered:
It does seem like the TCK and spec aren't matched on that point. That said, having the name be based on the base class or based on the extending class both seem reasonable -- so I don't think it would be worth changing our implementations to make them match the spec in this case.
We might go so far as to say that if we were to ever update the spec for other reasons and wanted to resolve this at the same time then we would plan to revise the spec to indicate that the metrics names in this inheritance scenario would use the name of the subclass not the name of the declaring class.
As Don pointed out in separate public communication in the Gitter channel, clarifying this by revising the spec would not break any existing applications because existing MP Metrics implementations already pass the TCK which uses the "subclass" approach rather than the "declaring class" approach. The change would simply align the spec with the existing TCK and behavior.
In the spec, the annotated naming conventions section in the second table (for annotations on a class) states that the metric name uses information (the package or canonical class name) of the declaring class, meaning the class which declares the method.
The TCK includes
AbstractTimedBean
with a class-level@Timed
annotation and atimedMethod
method.ConcreteExtendedTimedBean
extendsAbstractTimedBean
and addsanotherTimedMethod
.The TCK's
ConcreteExtendedTimedBeanTest#callTimedMethodOnce
test method invokestimedMethod
and makes sure the timer's count changes by 1. But interestingly to look up the timer to check the timer's count that test uses the subclass name. From the spec would we expect the test to look up the timer for the timedMethod method using the superclass name which is the declaring class of the method being invoked?Existing implementations of the spec pass the TCK but they and the TCK seem in conflict with the spec here.
The text was updated successfully, but these errors were encountered: