Hi Paul - I guess I knew that I could use UriInfo to solve this problem, but
I just couldn't figure out how to access the darn thing! I was looking at
how to use the ContainerRequest instance passed to the
ContainerRequestFilter's filter method and couldn't figure it out how to get
UriInfo there. Now my java intuition tells me this would be the only safe
place to handle per-request information like UriInfo because I can see that
the container is creating a single instance of my resource filter factory
and filter.
But based on your last comment about using UriInfo, I slapped @Context
UriInfo uriInfo; on my filter (didn't work), and then tried the same on the
factory, this worked! :) ... Now I apologize, this is a little mind bending
how this works since i'm storing per-request information in a member of an
instance that handles many requests.
Can you confirm this is a thread safe approach (i assume it is), and maybe
shed a little light why it's safe? I looked at the javadoc for
ResourceFilterFactory and didn't see any info on how annotations can be used
there.
I'll start digging up info on AbstractSubResourceLocator, this one is new to
me.
As always, thanks for reading/responding!
On Mon, Mar 1, 2010 at 8:33 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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
>>
>>
>
>