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.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.