Re: JSR311: expanded regexp and subresource locators

From: Bill Burke <>
Date: Mon, 14 Jul 2008 11:11:05 -0400

Marc Hadley wrote:
> On Jul 14, 2008, at 10:19 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.

>>>> 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.
>> The solution is simple. Change the damn servlet spec to have richer
>> url-patterns. Its ridiculous it is so limited and we have to define
>> our own JAX-RS specific resource security.
> I'm not opposed to doing that.
>>> 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.

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.


Bill Burke
JBoss, a division of Red Hat