Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec and TCK disagree on naming for metrics derived from annotations on superclasses #801

Open
tjquinno opened this issue Nov 22, 2024 · 3 comments

Comments

@tjquinno
Copy link
Contributor

tjquinno commented Nov 22, 2024

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.

@donbourne
Copy link
Member

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.

@tjquinno
Copy link
Contributor Author

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.

@tjquinno
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants