I don't know...
IMO, just don't have a TCK test for it ;-)
Stephan Koops wrote:
> Yes Bill, you are right. I mean especially, where @Path("{var}/{var}")
> is needed in one @Path. Is there any usecase for it?
>
> best regards
> Stephan
>
> Bill Burke schrieb:
>> Because u may not know your subresource is being reuse. A subresource
>> may be from another project or even a third party. I just don't see a
>> problem with multi-varnames....
>>
>> Replace {var} with {id} and Foo/Sub with Customer/Address and maybe u
>> see what i mean.
>>
>> Bill
>>
>> Stephan Koops wrote:
>>> Why not use
>>>
>>> @Path("/")
>>> public class Foo
>>> {
>>> @Path("{varA}")
>>> public Sub get() {}
>>> }
>>>
>>> public class Sub
>>> {
>>> @Path("{varB}")
>>> @GET
>>> public String get() {}
>>> }
>>>
>>> with different names (varA, varB) instead of the same in both cases?
>>>
>>> best regards
>>> Stephan
>>>
>>> Bill Burke schrieb:
>>>> Well, I see the following example alot. Especially for
>>>> sub-resources fronting a DB that are reused.
>>>>
>>>> @Path("/")
>>>> public class Foo
>>>> {
>>>> @Path("{var}")
>>>> public Sub get() {}
>>>> }
>>>>
>>>> public class Sub
>>>> {
>>>> @Path("{var}")
>>>> @GET
>>>> public String get() {}
>>>> }
>>>>
>>>> Stephan Koops wrote:
>>>>> Hi all,
>>>>>
>>>>> does anyone knows a usecase where it is useful to require
>>>>> @Path("{var}/{var}"), with respect to the resource oriented
>>>>> architecture?
>>>>> As Paul said, IMO everytime @Path("{varA}/{varB}") would work.
>>>>> If there is no usecase, let forbid it. Or at least let recommend to
>>>>> not use it and accept unexpected behaviours, if not both {var}s
>>>>> matches the same value.
>>>>> Than we have no problems with {"1", "3/4"} or {"1", "3", "4"}.
>>>>>
>>>>> best regards
>>>>> Stephan
>>>>>
>>>>> Paul Sandoz schrieb:
>>>>>> Marc Hadley wrote:
>>>>>>> On May 21, 2008, at 12:03 PM, Paul Sandoz wrote:
>>>>>>>>> An oversight, for consistency I guess we should allow the
>>>>>>>>> collection types too. So given:
>>>>>>>>> @Path(value="{p}/foo/{p}", limited=false)
>>>>>>>>> @PathParam("p") List<String> paths
>>>>>>>>> GET /1/foo/3/4
>>>>>>>>> Should paths be:
>>>>>>>>> {"1", "3/4"}
>>>>>>>>> or
>>>>>>>>> {"1", "3", "4"}
>>>>>>>>> I think this should inform the decision we make re
>>>>>>>>> @PathParam("p") List<PathSegment> paths. I'd like some
>>>>>>>>> consistency with how the path is split up regardless of the
>>>>>>>>> type of list - i.e. I'd rather not special case PathSegment.
>>>>>>>>
>>>>>>>> It breaks the consistency with template creation and will result
>>>>>>>> in an error when using such matched values for URI creation from
>>>>>>>> a URI template. I think {p} MUST have the same value for
>>>>>>>> matching and creation. The workaround is trivial: use another
>>>>>>>> template name for the second one.
>>>>>>>>
>>>>>>> I'm conflicted on this one. I agree its odd and easily worked
>>>>>>> around but given that you can already do:
>>>>>>>
>>>>>>> @Path("{var}")
>>>>>>> public class RootResource {
>>>>>>>
>>>>>>> @Path("{var}")
>>>>>>> public SubResource locator(@PathParam("var") String var) {...}
>>>>>>> }
>>>>>>>
>>>>>>> and GET /1/2 will call locator("2") it doesn't seem much of a
>>>>>>> stretch to support:
>>>>>>>
>>>>>>> @Path("{var}")
>>>>>>> public class RootResource {
>>>>>>>
>>>>>>> @Path("{var}")
>>>>>>> public SubResource locator(@PathParam("var") List<String> vars)
>>>>>>> {...}
>>>>>>> }
>>>>>>>
>>>>>>> where GET /1/2 will call locator({"1","2"}). If that works then
>>>>>>> it would be surprising if
>>>>>>>
>>>>>>> @Path("{var}/{var}")
>>>>>>> public class RootResource {
>>>>>>>
>>>>>>> @GET
>>>>>>> public Result get(@PathParam("var") String var) {...}
>>>>>>> }
>>>>>>>
>>>>>>> didn't call get({"1","2"}).
>>>>>>>
>>>>>>
>>>>>> I don't find it so surprising :-) The later is one URI template
>>>>>> where as the others are two separate URI templates that are
>>>>>> matched separately. When combining templates certain rules
>>>>>> (specified the by the URI template draft) come into force, as is
>>>>>> the case when combining for URI construction.
>>>>>>
>>>>>> If I use the URI builder (or any other conforming URI template
>>>>>> implementation) to construct a URI from "{var}/{var}" then i can
>>>>>> only assign one value to "val".
>>>>>>
>>>>>> So i guess it comes down to whether we want round trip consistency
>>>>>> for matching and construction.
>>>>>>
>>>>>> Paul.
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com