Paul Sandoz wrote:
> Peter Liu wrote:
>> This looks exactly what we need. When will this be implemented in
>> jersey?
>>
>
> I may start working on it next week but it will most likely be middle
> to end of September when a stable release will appear (0.3.x).
>
> Terminating a URI template with a '/' also has another function: if
> the matching request URI does not terminate with a '/' then the client
> is redirected to a request URI that terminates with a '/'.
>
So, is it recommended that we generate "/"?
Peter
> Paul.
>
>> Thanks.
>>
>> Peter
>>
>> Marc Hadley wrote:
>>> See the path method of the new UriBuilder class in the 311 API
>>>
>>> https://jsr311.dev.java.net/source/browse/jsr311/trunk/src/jsr311-api/src/javax/ws/rs/core/UriBuilder.java?rev=64&view=markup
>>>
>>>
>>> Its not yet implemented in Jersey but hopefully that will meet your
>>> requirements when it is implemented. To do what you describe below
>>> you'd write something like:
>>>
>>> URI uri =
>>> UriBuilder.fromResource(SomeResource.class).path(subResourcePath).build();
>>>
>>>
>>> if SomeResource has a URI template of "foo" and subResourcePath is
>>> "bar" then uri will be "foo/bar".
>>>
>>> If you are in the resource for which you want to make a sub resource
>>> URI you'll also be able to write
>>>
>>> URI uri = uriInfo.getUriBuilder().path(subResourcePath).build();
>>>
>>> since UriInfo know the current request URI.
>>>
>>> Marc.
>>>
>>> On Aug 2, 2007, at 4:21 PM, Peter Liu wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> Here is the context. Currently, when we generate the UriTemplate,
>>>> we append it with "/".
>>>> The reason is to make it easy for us to create an uri for a
>>>> subresource from the parent
>>>> uri by using the resolve() method since the resolve() strips off
>>>> the last segment in the uri.
>>>>
>>>> So, the question is whether there is another simple way to achieve
>>>> the same result
>>>> without us having to append a "/".
>>>>
>>>> Thanks.
>>>>
>>>> Peter
>>>>
>>>> Nam Nguyen wrote:
>>>>> Hi Paul,
>>>>>
>>>>> Could you please explain (again?) the reason for this
>>>>> requirement. It seems to me this is just some temporary
>>>>> work-around rather than be part of JSR specs.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Nam
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>>
>>>
>>> ---
>>> Marc Hadley <marc.hadley at sun.com>
>>> CTO Office, Sun Microsystems.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>