I just want to add that option (b) is the only option I think because
PathSegment should never have more than one uri segment value because of
matrix parameters. Currently a PathSegment is the only way of obtaining
re-occuring matrix parameters, a PathSegment with multiple uri segments
as its value breaks this.
Bill Burke wrote:
> +2 option (b).
>
> Paul Sandoz wrote:
>>
>>
>> Marc Hadley wrote:
>>> Attached is a HTML table that outlines what I see as the possible
>>> values of var depending on type T in:
>>>
>>> @Path(value="{var}" limited=false)
>>> public class SomeResource {
>>> @GET
>>> public SomeType get(@PathParam("var") T var) {...}
>>> }
>>>
>>> for a request
>>>
>>> GET /1/2/3.
>>>
>>> As pointed out earlier in the thread, options (a) and (d) don't
>>> really work for PathSegment since that is designed to represent a
>>> single path segment rather than multiple. IMO, option (c) gives a
>>> surprising result for String which really only leaves option (b) as
>>> viable. Option (b) is a bit odd since the results are quite different
>>> depending on the type T but its already the case that PathSegment is
>>> special (it extracts the whole path segment even if the referenced
>>> template variable has adjacent literal characters) so I think I can
>>> live with that.
>>>
>>
>> +1 on option (b).
>>
>> Paul.
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com