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.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.