Re: common handling of path param

From: Trolly Rogers <>
Date: Thu, 25 Feb 2010 11:27:27 -0500

I spoke too soon about my superclass solution... i had my app in mock mode
so it appeared to work. Back to the drawing board.

On Wed, Feb 24, 2010 at 9:51 PM, Trolly Rogers <>wrote:

> Hi All - Hope I'm not being a pest. I just can't figure out how to handle
> some common logic needing to be applied to a common path param (at least the
> way I'd like to). I have a bunch of resources which all share a couple
> things I mentioned below. There's basically one root resource, and a number
> of sub-resources exposed via method and locator. Here's the two things they
> all have in common...
> 1. part of thier URIs. They all begin with /users/{id}. The id is not the
> user's user id exactly, but it is a unique way to identify the user and
> provides a great piece of scoping info keeping my URIs RESTful.
> 2. The {id} path param needs to be checked against the value of
> HttpServletRequest's getUserPrincipal().getName(). This name is set as part
> of our security infrastructure and ensure the {id} passed to my resource is
> in fact the right user.
> I thought I was on to something when I was workin' on my own
> ResourceFilterFactory impl. The thing I got hung up on was how to get the
> value of the resolved {id} path param, is this possible in a
> ContainerRequestFilter?
> The solution I have working now is basically having my resource classes sub
> class "UserIdAuthBasedResource" which provides a constructor forcing any sub
> classes to pass in the user id and HttpServletRequest for the common
> checking (#2). There's obvious disadvantages here (but it works), any
> suggestions?
> Thanks,
> Trolly