On Apr 5, 2010, at 3:35 PM, Marc Hadley wrote:
> The only partial solution that occurs to me is to use the
> UriInfo#getMatchedResources method to obtain the resource classes
> and then use reflection to get the value of the @Path annotation. I
> think this would work OK for root resource classes but could get
> very complicated if you are using subresource locators.
>
For the first problem you may be able to use a ResourceFilter
associated with the resource methods:
https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/container/filter/package-summary.html
Injecting ExtendedUriInfo may help for the second point:
https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/core/ExtendedUriInfo.html
It allows one to get access to the list of MatchResult and UriTemplate
(essentially the @Path value converted to an instance of UriTemplate).
Paul.
> Marc.
>
> On Apr 4, 2010, at 4:59 PM, Mike Duigou wrote:
>
>> I am working on adding JMX metrics for method invocations to a
>> medium sized Jersey-based REST implementation. I can easily capture
>> the raw request URI from the UriInfo at the time resource objects
>> are created with getRequestURI(). I would like to extend this to
>> capture the parameterized @Path URIs.
>>
>> Currently I can capture:
>>
>> http://example.com/clients/99/invoices/42/items/1?search=foo+bar
>>
>> Which I record as both:
>>
>> /clients/99/invoices/42/items/1
>> /clients/99/invoices/42/items/1?search=foo+bar
>>
>> I'd also like to capture the parameterized version:
>>
>> /clients/{client}/invoices/{invoice}/items/{item}
>>
>> I've run into two problems:
>>
>> - The UriInfo presented at Resource construction time only includes
>> getMatchedURIs() for the Resource class not the the complete match
>> for the method it will eventually call. ie. a different UriInfo is
>> presented at method invocation than at resource construction. ("/
>> clients/99" rather than the full "/clients/99/invoices/42/items/
>> 1"). The implication for what I am trying to do with JMX is that I
>> have to add code to every method to record the invocation. I had
>> hoped to handle the JMX metrics transparently within my resource
>> base class constructor but this doesn't seem possible.
>>
>> - UriInfo getMatchedURIs() seems to provide only the regular
>> expression used for matching and doesn't identify the parameters.
>> You can get the parameters via getPathParameters() but there is
>> doesn't seem to be a way to associate them back to the match
>> expression.
>>
>> Is there perhaps a different choke point that I should be
>> instrumenting rather than my abstract resource base class? Is there
>> a filter point which sees all requests in their @Path form that I
>> could attach to? Are there any alternative places I could hook in
>> to gather metrics? After these request metrics I expect that I will
>> be trying to add request timing metrics so any solutions which help
>> for addressing that would be preferred.
>>
>> TIA,
>>
>> Mike
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>