I agree, it's not a good fit, but the API is a) not really documented regarding overall behavior and b) mostly implemented in private classes.
If folks here have a better idea for how to decorate the underlying ResourceMethodDispatch instance in a cleaner way, I'd change this in a heartbeat.
--
Coda Hale
http://codahale.com
On Thursday, December 29, 2011 at 2:13 PM, Marshall Pierce wrote:
> On 12/28/2011 05:25 PM, Coda Hale wrote:
> > 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,
> First of all, thanks for Metrics. :)
>
> That's an interesting approach. I hadn't noticed the
> ResourceMethodDispatchProvider extension point before. (Are all these
> various provider and factories documented somewhere I haven't found, or
> do I just need to chase down every usage of an interface that ends with
> 'Provider' or 'Factory'?)
>
> I do have a few reservations, though. It looks like subclassing
> EntityParamDispatchProvider would effectively route all requests through
> EPDP since InstrumentedResourceMethodDispatchProvider would be checked
> before the system-provided implementations. (Unless EPDP would return
> null for a given request, in which case no metrics would be applied,
> though it doesn't like like this would happen in practice.) I could be
> off base here; I haven't had time to try this out yet so I'm not sure if
> it behaves this way in practice. Ideally I'd like to let the default
> dispatch provider selection mechanism follow the normal path and then
> apply metrics around whatever it selects. It looks like this mechanism
> also wouldn't play nice if I wanted my own separate dispatch provider to
> be used, though I might be misunderstanding how dispatch provider
> selection works.
>
> It'd also be nice to abstract out the application of metrics to a given
> AbstractResourceMethod. Ideally I'd like to be able to register my own
> code to decides not only what to name the per-AbstractResourceMethod
> metric but whether or not the metric is used at all. In other words,
> while I think those annotations are useful, I'd like to be able to apply
> timing (or any other metric) to *all* resource methods without having to
> put @Timed on each of them.
>
> Marshall