SmallRye Metrics - JandexBeanInfoAdapter does not reflect changes made by AnnotationTransformer

[mkouba]

So for example, if you add the @Counted annotation to a bean class you'll get a UnsupportedOperationException at runtime:

Caused by: java.lang.UnsupportedOperationException
	at io.smallrye.metrics.interceptors.MetricResolver$DoesNotHaveMetric.metricName(MetricResolver.java:182)
	at io.smallrye.metrics.interceptors.CountedInterceptor.countedCallable(CountedInterceptor.java:86)
	at io.smallrye.metrics.interceptors.CountedInterceptor.countedMethod(CountedInterceptor.java:70)

@jmartisk it should be possible to make use of AnnotationStore obtained via io.quarkus.arc.deployment.ValidationPhaseBuildItem.getContext().

[jmartisk]

Good catch, this prevents us from adding metric annotations dynamically, which could be valid usage for some extensions. I will look into it

[mkouba]

Good catch, this prevents us from adding metric annotations dynamically, which could be valid usage for some extensions.

Yep, we've found the issue when working on a demo extension for our "Code Your First Supersonic Extension" workshop for DevConf.cz ;-)

[jmartisk]

What you described seems to be just the first half of the problem. Jandex adapters are used only during build, then discarded after metrics are registered. At runtime, for matching a request to the relevant metrics, CDI adapters are used (see https://github.com/smallrye/smallrye-metrics/blob/2.3.2/implementation/src/main/java/io/smallrye/metrics/interceptors/CountedInterceptor.java#L80 ) which are based on using reflection. Now the second half of the problem is that the annotation added by a transformer is not visible using reflection at runtime, so the matching doesn't work. Do you know how to make it visible?

[mkouba]

Now the second half of the problem is that the annotation added by a transformer is not visible using reflection at runtime, so the matching doesn't work.

How do you proceed with CDI full? Is the matching based on the Annotated layer?

[mkouba]

I mean if it was based on reflection it wouldn't work for Weld either, or?

[manovotn]

I mean if it was based on reflection it wouldn't work for Weld either, or?

Nope, it wouldn't. But maybe nobody tried adding it programatically yet ;-)

Either way, in Weld you have full metadata whereas in Quarkus you don't and you cannot just make those programatically added annotations visible. Maybe you need to do something similar to what Michal did for security annotations? E.g. gather all data about annotated fields/classes at build time and expose a bean that holds them so you can "inspect" it at runtime?
I might just be blabbering though :-)

[jmartisk]

We cast it to AnnotatedElement, see https://github.com/smallrye/smallrye-metrics/blob/2.3.2/implementation/src/main/java/io/smallrye/metrics/elementdesc/adapter/cdi/CDIMemberInfo.java#L75
input is an instance of java.lang.reflect.Method

[mkouba]

Well, that's java.lang.reflect.AnnotatedElement. I was talking about CDI SPI - javax.enterprise.inject.spi.AnnotatedType and friends.

[mkouba]

Matej is right. If you need the metadata at runtime you'll likely need to record the metadata at build time and expose it via a bean. See for example io.quarkus.security.deployment.SecurityProcessor.gatherSecurityChecks() and https://github.com/quarkusio/quarkus/blob/master/extensions/security/runtime/src/main/java/io/quarkus/security/runtime/interceptor/SecurityCheckStorageBuilder.java.

[jmartisk]

Ok then that makes it a bit complex, because it will need changes on SmallRye Metrics side. I like the approach with SecurityCheckStorageBuilder and think something similar could be used in SmallRye for storing the (pre-computed) mapping between methods and metrics so we won't have to use runtime reflection to determine it on-the-fly. But as this kinda is an architectural change for SmallRye Metrics, I can just hope you're not relying on this being ready before DevConf :) I can get to it after the Christmas break, but can't really promise now