FWIW, I've just added a metrics-jersey module to Metrics 2.0.0-BETA19-SNAPSHOT which has a ResourceMethodDispatchProvider implementation which adds support for all @Timed/_at_Metered/_at_ExceptionMetered-annotated resource methods:
https://github.com/codahale/metrics/blob/master/metrics-jersey/src/main/java/com/yammer/metrics/jersey/InstrumentedResourceMethodDispatchProvider.java
Feedback appreciated.
--
Coda Hale
http://codahale.com
On Wednesday, December 28, 2011 at 12:18 PM, Marshall Pierce wrote:
> Hi,
> I'm trying to find a minimally invasive way of capturing various
> statistics about Jersey resource method invocation. It's pretty easy to
> hook into the inbound and outbound flow via
> com.sun.jersey.spi.container.ResourceFilterFactory and that should work
> fine for things like measuring the frequency of 5xx status codes.
> However, that doesn't offer an easy way to actually wrap an individual
> invocation the way javax.servlet.Filter does.
>
> This is what I'm trying to do conceptually (from
> http://metrics.codahale.com/getting-started.html):
>
>
> final TimerContext context = ...;
> try {
> // invoke resource method
> } finally {
> context.stop();
> }
>
>
> The goal is to be able to use a TimerContext (and other metrics) that
> are tied to each individual AbstractMethod so that I can see data for
> "GET /foo/{fooId}" without having to map "/foo/33" and "/foo/96" to the
> proper resource myself.
>
> It looks like one approach might be to combine a request-scoped
> TimerContext that gets set in a ContainerRequestFilter with a servlet
> Filter that actually measures the time and applies the measured
> invocation time to the timer. This feels messy, though.
>
> I can also do it via AOP, and that's not necessarily a bad way to go. I
> don't object to AOP; I'm just curious if I can do it cleanly without AOP.
>
> Any suggestions for a better way to do this?
>
> -Marshall