Re: [Jersey] common handling of path param

From: Trolly Rogers <>
Date: Thu, 25 Feb 2010 17:26:39 -0500

Thank you kindly, Marc. This approach definitely works.

Strictly from a design perspective... I just wish I could figure out a way
to completely decouple this and let my resources just be concerned about
being resources. This would also mean the solution is reusable since other
groups (where i work) who use {id} can just configure the solution w/out
impacting and/or dictating how they design their resources.

ResrouceFilter via custom ResourceFilterFactory seems like a great fit, I
just can't figure out how (or if it's possible) to get the resolved path
param value of a given request.

On Thu, Feb 25, 2010 at 1:29 PM, Marc Hadley <> wrote:

> One approach you could use is subresource locators. E.g.
> @Path("/users/{id}")
> public class UserResource {
> public UserResource(@PathParam("id") String id) {
> // do whatever common work is required
> }
> @Path("some/sub/path/1")
> public SomeSubPath1Resource getSubPath1Resource() {
> // instantiate whatever kind of resource is appropriate
> // based on work done in constructor
> }
> ...
> }
> The getSubPath1Resource method returns an instance of a resource class to
> handles the actual request (e.g. a class with @GET, @POST ect methods.
> Marc.
> On 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: