On Nov 3, 2008, at 1:02 PM, Paul Sandoz wrote:
> Hi Tim,
>
> On Nov 3, 2008, at 8:34 PM, Tim Pesce wrote:
>
>> I have a scenario where I'd like to extract a path parameter into a
>> query parameter. So URIs of the form:
>>
>> /context/scope/{scopeid}/resource
>>
>> would become:
>>
>> /context/resource?scope=scopeid
>>
>> My initial approach was to create a ContainerRequestFilter and
>> modify the request's URIs via ContainerRequest.setUris(). However,
>> this approach does not seem viable because the path is calculated
>> prior to filter invocation (from
>> WebApplicationImpl._handleRequest()):
>>
>
> Drat, that is a bug. The path needs to be obtained after filters
> have been applied. Also the request filter can return a new request
> so that needs to be catered for as well. Could you log an issue?
>
Will do!
>>
>> My new plan is to perform this transformation via Servlet filter,
>> but given the earlier discussion around per-resource filters and
>> issue #134 I'm wondering if this use case may be something that
>> Jersey can more directly support in the future. Also more
>> generally, are there better approaches for handling this scenario
>> within Jersey?
>>
>
> You can do it explicitly with resource classes and reuse code:
>
> @Path("content")
> public class ResourceContext {
> @Path("scope/{scopeid}/resource"
> @GET
> ... getAsPath(@PathParam("scopeid") String scope) {
> return getAsQuery(scope);
> }
>
> @Path("resource")
> @GET
> ... getAsQuery(@QueryParam("scope") Scope scope) { ... }
> }
>
> I suspect that is not what you want.
>
> Like Jeff i am curious as to why you want to do this to understand
> your use-case better.
>
As you and Jeff point out, dealing with this kind of situation in
general is really easy with JAX-RS, and this is one of the reasons
I've been really fond of working with it (and Jersey!). My use case is
related to deployment requirements and more specifically the ability
to match differing URL conventions for different but related
applications.
In all cases there is the concept of a scope at the resource level. In
some applications the scope is variable and supplied as a path
parameter, while in others the scope has an implied default (not
specified via URL). Furthermore, different applications have different
"prefix" components for the scope (e.g. /container/{scopeid}, /folder/
{scopeid}) and there may be a need to provide valid resources only if
the application-specific prefix was used.
I'm trying to keep the resource classes simple by decoupling the scope
mapping issues, and my original thoughts were around providing
application-specific filters. I hadn't thought of your "getAsPath"
suggestion, though in my case I'm not sure it would be quite as clean
as I'd like. In my original example "/context" was intended to be the
baseURI of the request, so I'd need to map both scoped and non-scoped
paths to the same logical root resource. I'll have to dig into this
more; I may be able to do what I want by using simple application-
specific root resources instead of filters.
Thanks!
Tim