@Timed, @Metered @ExceptionHandler on jersey2 inherited resources don't work

[vrcar]

My dropwizard app stop working when I migrate it from 0.7.1 to 0.8.X (metrics-jersey to metrics-jersey2). The problem is with inherited resources and metrics. In “metrics/jersey2/InstrumentedResourceMethodApplicationListener.java” timers, meters and exceptionMeters maps use java.lang.reflect.Method as key. So when a child resources try to register annotations it fails due a duplicate key (the parent method is already registered by a different resource). I saw in the previous metrics-jersey module that annotations was registered using the resource class name and the method. I think this approach should work in the jersey2 implementation if there is no side effects changing Method key to String in the maps.

I work in my own fix, could this help?

[marshallpierce]

Unfortunately, counting on method name won't always work like it did in jersey 1. Jersey 2 lets you do more complicated ways of applying logic that don't really have a useful method name, e.g.:

  final Resource.Builder resourceBuilder = Resource.builder();
        resourceBuilder.path("programmaticResource");

        final ResourceMethod.Builder methodBuilder = resourceBuilder.addMethod("GET");
        // using a lambda makes jersey sad because it can't reflectively access the type
        //noinspection Convert2Lambda
        methodBuilder.produces(MediaType.TEXT_PLAIN_TYPE)
            .handledBy(new Inflector<ContainerRequestContext, Object>() {
                @Override
                public Object apply(ContainerRequestContext containerRequestContext) {
                    return "Such dynamic. Very resource. Wow.";
                }
            });

        final Resource resource = resourceBuilder.build();
        registerResources(resource);

That's one of the reasons I started my own jersey2 integration (https://bitbucket.org/marshallpierce/jersey2-metrics).

[vrcar]

Ok, I miss that... Then use the http verb + path instead of class name + method name? I can try to arrange it if it's the right approach.

[marshallpierce]

This is one of the options my project has; see https://bitbucket.org/marshallpierce/jersey2-metrics/src/9cf28f8e5292486449a17893915980bdee575f31/jersey2-metrics-core/src/test/java/org/mpierce/jersey2/metrics/RequestPathMetricNamerTest.java?at=master#RequestPathMetricNamerTest.java-75 for instance.

There is a performance cost to getting the path components from Jersey; I've been meaning to get around to filing a bug with Jersey to provide a less painfully slow way of assembling the path but haven't done so yet.

[marshallpierce]

I take it back: upon more careful benchmarking, it looks like the performance cost of using the request path is pretty negligible.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove the "stale" label or comment or this will be closed in 14 days.