I think there's an easy fix for this by substituting (.+?) for the
existing (.*?) in section 3.7.3 step 4. I don't have time right now to
test it so I'd be interested in any feedback before I get round to it
in the next couple of days. There may be other side effects though...
Marc.
On Jul 10, 2008, at 6:44 PM, Sergey Beryozkin wrote:
> Hi
>
> Using 0.9 spec….Consider this class
>
> @Path(“/”)
> public class ResourceClass {
>
> @GET
> @Path(“/foo”)
> Public String get1() {}
>
>
> @GET
> @Path(value=“/foo/{id}”, limited=false)
> Public String get2() {}
>
>
> }
>
> requests like ‘/foo/’ (note the trailing ‘/’) are matched against
> get2(). If get2() had a limited path expression then the request
> will be matched against get1()
> so there’s some inconsistency here – I suppose it may not too bad
> given that we have an unlimited path expression in this case ?
>
>
> Now, if we have
>
> @Path(“/”)
> public class ResourceClass {
>
> @GET
> Public String getAll() {}
>
>
> @GET
> @Path(value=“/{id}”, limited=false)
> Public String getId() {}
>
>
> }
>
> then ‘/’ request will match getId().
> Both getAll() and getId() match initially, but ‘sort in descending
> order using the number of capturing groups’ constraint
> selects getId(). Note it’s the same issue we’ve chatted before
> about, but that one was to do with using limited path expressions –
> it’s fixed now, this time it’s an unlimited path
> which is used.
>
> I’m wondering is there something which can be done to make sure
> getAll() is selected in this case ?
>
>
> Cheers, Sergey
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.