Re: JSR311: expanded regexp and subresource locators

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 14 Jul 2008 09:53:04 -0400

On Jul 12, 2008, at 4:57 PM, Bill Burke wrote:

> Was thinking more about our possible regexp expansion. One thing
> that screws it up is Subresource Locators. For example:
> @Path("{foo:.*}")
> public Object find(@PathParam("foo") String foo)
> {
> return new Bar();
> }
> public class Bar {
> @Path("a/b/c")
> @GET
> public String get() {}
> }
> Let's say the HTTP request is:
> GET /a/bunch/of/stuff/a/b/c
> @PathParam foo would always eat up the whole URI.
> This is yet another thing I dislike about dynamic Subresource
> locators.

I don't think this is a problem with sub-resource locators per-se, its
just an issue of being careful with your @Path values. That will apply
in spades if we allow specification of the regex for a path param.

> If you don't remember I also talked about the problem of not being
> able to authenticate before invoking on the resource locator since
> you would need @RolesAllowed available.
On that topic I've been working with our EE security architect to try
to come up with a solution. We don't have anything fully baked yet but
are thinking along the lines of specifying a servlet 3 compatible path
that would point at JAX-RS resource classes rather than identifying
URI paths. With this you'd be able to put something like this in a
web.xml to constrain access to a resource:

         <description>Have to be a user to POST to the Foo resource

Or something like that anyway.


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.