Re: JSR311: expanded regexp and subresource locators

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 14 Jul 2008 11:50:17 -0400

On Jul 14, 2008, at 11:11 AM, Bill Burke wrote:
>>>> 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.
>>> No, its a problem with sub-resource locators. Consider this:
>>> @Path("/")
>>> public class FindJmsQueue {
>>> @Path("{path:.*}")
>>> public QueueResource find(@PathParam("path") String lookup) {
>>> Destination queue = jndi.lookup(lookup);
>>> return new QueueResource(queue);
>>> }
>>> }
>>> I'm decoupling the lookup from the actual resource that handles
>>> Queue processing. If JAX-RS only did static sub-resource
>>> locators, I could have any arbitrary path followed by concrete,
>>> well-known, resource endpoints. I hope you're following me. I
>>> know others have shown similar examples to this.
>> I don't see the problem. If the QueueResource methods don't have
>> their own @Path then everything will work fine.
> At least in this example, QueueResource *does* have its own @Path's.
Then it won't work. If you need to consume the entire path with a
parent resource you'll have to write the sub-resource differently.
Again, I don't think that's a problem with sub-resource locators per-se.

>>>> 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:
>>>> <security-constraint>
>>>> <display-name>Constraint1</display-name>
>>>> <web-resource-collection>
>>>> <web-resource-name>Foo</web-resource-name>
>>>> <url-pattern>jaxrs:///resources/Foo</url-pattern>
>>>> <http-method>POST</http-method>
>>>> </web-resource-collection>
>>>> <auth-constraint>
>>>> <description>Have to be a user to POST to the Foo resource
>>>> class</description>
>>>> <role-name>USERS</role-name>
>>>> </auth-constraint>
>>>> </security-constraint>
>>> Unless I'm missing something, seems very very very very Glassfish
>>> specific. No thanks...
>> What makes it Glassfish specific ? All those elements are standard
>> web.xml element from Servlet...
> I thought url-patterns could only be relative URLs.
Like I said, its only a half-baked idea at this point.

> FYI, yet another problem I have with dynamic locators is that I want
> to do secure server-side caching. I can't fully avoid doing
> processing because I have to resolve dynamic sub-resources.
> I guess what I'm getting at is that maybe more metadata is needed to
> specify whether the subresource is static or dynamic.
Perhaps you could experiment with some new annotation to specify what
you need and bring that to the EG once you have something concrete to
propose ?


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