On Jan 26, 2010, at 10:54 AM, Reto Bachmann-Gmuer wrote:
>
> You're right where I wrote .+ I actually meant .*.
>
OK. That looks like a useful tweak to the matching algorithm and I can't see any downsides. Could you create an issue for it so we can keep track of it.
Thanks,
Marc.
>
> On Tue, Jan 26, 2010 at 4:46 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>> On Jan 26, 2010, at 10:24 AM, Reto Bachmann-Gmuer wrote:
>>>
>>> According to section 3.7.2 when there is no path left after the path
>>> of the resource class only resource methods but not sub-resource
>>> method may be selected. I think it would be useful to be able to
>>> return another object to handle the request also for the root of the
>>> resource.
>>>
>>> For example I would like the following class to delegate any request
>>> to the instance of WidgetResource returned by WidgetResourceFactory:
>>>
>>> @Path("")
>>> public class WidgetsResource {
>>>
>>> @Path("{path:.+}")
>>> public WidgetResource findWidget(@Context UriInfo uriInfo) {
>>> return new WidgetResourceFactory.getWidgetResourceByUri(uriInfo.getAbsolutePath())
>>> }
>>>
>>> }
>>>
>> Is the problem here that GET / wouldn't call the findWidget method whereas GET /anything/else would ?
>>
>>> public class WidgetResource {
>>>
>>> @GET
>>> public Widget getDetails() {...}
>>>
>>> @PROPFIND
>>> public Object() {...}
>>>
>>> }
>>>
>>>
>>> The concrete use case is that in Apache Clerezza we want to redirect
>>> to a Resource Class based on the type of the requested resource in an
>>> underlying RDF model if no regular root resource class could be
>>> located for the specific path. Currently we are doing this with an
>>> explicit call back via a non-standard extension[1] of the jax-rs
>>> implementation, however this is quite odd as for every http method
>>> (including any extension) we need to add a new resource method to the
>>> forwarding class.
>>>
>>> I think a slight generalisation of the spec could satisfy our needs,
>>> the minimalist way to achieve this would be to change in section 3.7.2
>>> 2 (a) "and go to step 3" to "if M is not empty go to step 3".
>>>
>> I'm not sure how that would help, if U is empty then it won't match any sub resource methods anyway (unless they used a template like .* I suppose). Did you mean .* in the first example rather than .+ ?
>>
>> Marc.
>>
>>> I believe such a change would also be useful in other situations, in
>>> fact I've been writing constructs like the following several time:
>>>
>>> @Path("widgets")
>>> public class WidgetsResource {
>>>
>>> @GET
>>> public Widget getRootWidget(@Context UriInfo uriInfo) {
>>> return getWidget(uriInfo);
>>> }
>>>
>>> @GET @Path("{path:.+}")
>>> public Widget getWidget(@Context UriInfo uriInfo) {...}
>>> }
>>>
>>> It seems awkward to have to write that extra method for when there is
>>> no path left.
>>>
>>> Cheers,
>>> reto
>>>
>>>
>>> 1. http://svn.apache.org/viewvc/incubator/clerezza/trunk/org.apache.clerezza.parent/org.apache.clerezza.jaxrs.extensions/src/main/java/org/apache/clerezza/jaxrs/extensions/RootResourceExecutor.java?view=markup
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>