Marc Hadley wrote:
> On May 21, 2008, at 4:20 AM, Stephan Koops wrote:
>> Ok, then we have
>>> @Path(value="ab{CDEF}", limited=false)
>> and
>>> @PathParam("{CDEF}") PathSegment ps
>> with "ab12/34/56" to match. What it the path in the PathSegment? "12"?
>> "56"? "12/34/56"? The first and second is IMO not useful and the last
>> is not realy one path segment.
>
> Yes, this is a tricky one.
>
>> Marc, 6 weeks ago we discussed if @Path("{p}/abc/{p}") should be
>> allowed or not. (my request:
>> https://jsr311.dev.java.net/servlets/ReadMsg?list=users&msgNo=187,
>> section "Annotations in root resource classes"; your answer:
>> https://jsr311.dev.java.net/servlets/ReadMsg?list=users&msgNo=191).
>> You said that it is allowed, but also agreed with me, that it is odd.
>> You argued, that a developer could read it by
>> UriInfo.getPathParameters(), which returns a MultivaluedMap. Why are
>> List, Set and Sorted Set not allowed for @PathParam (Perhaps only List) ?
>
> 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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109