On Feb 25, 2010, at 11:26 PM, Trolly Rogers wrote:
> 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.
>
You can use UriInfo to get the map of path parameters currently in
scope. See UriInfo.getPathParameters. Is that what you want?
When using ResourceFilterFactory you can utilize
AbstractSubResourceLocator, obtaine the PathValue, parse it using
UriTemplate and then obtain the template variables or path parameter
names. That way you may be able to avoid hardcoding path parameter
names.
Paul.
>
> On Thu, Feb 25, 2010 at 1:29 PM, Marc Hadley <Marc.Hadley_at_sun.com>
> 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: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>