I know I'm not answering your question, but I'm curious about where the
need for this comes from. Path parameters are no harder for a resource
class to deal with that query parameters; they're just an annotation
away.
-----Original Message-----
From: Tim Pesce [mailto:tpesce_at_foxfish.com]
Sent: Monday, November 03, 2008 2:35 PM
To: users_at_jersey.dev.java.net
Subject: [Jersey] Transforming paths via filter
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()):
---
StringBuilder path = new StringBuilder();
path.append("/").append(localContext.getPath(false));
[....]
for (ContainerRequestFilter f : requestFilters)
request = f.filter(request);
if (!rootsRule.accept(path, null, localContext)) {
throw new NotFoundException();
}
---
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?
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net