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