Hi Stephan
Thanks for your advice.
It actually works in our implementation too :-), but I'm wondering if it's the right behaviour or not...
Just for brewity, I'll omit ProduceMime declarations. By the way, I thought ProduceMime is an optional thing, the default is "*\*" ?
For example :
@Path("/")
class SomeClass {
@GET
@Path("bar")
public Bars getBars() {}
@GET
@Path("bar/{id}")
public Bar getBar(@PathParam String id) {}
}
At the moment, CXF wrongly matches /bar/1 request to getBars(). Both methods match "bar/1", but in case of getBars the final matching group is "/1", thus, according 2.5.2.d section, getBars() needs to be eliminated, If it's correct then the same should happen for "/bar/"...
Thanks, Sergey
> Hello Sergey,
>
> you must add a @ProduceMime to the sub resource method. Than it works
> with my JAX-RS implementation.
> And you need an MessabeBodyWriter for Bar and the given @ProduceMime.
>
> If Bar is a resource class than you must remove the @GET from getBar()
>
> best regards
> Stephan
>
> Sergey Beryozkin schrieb:
>> Hi
>>
>> I have few questions about matching requests to subresource methods.
>>
>> Consider this class :
>>
>> @Path("/")
>> class SomeClass {
>>
>> @GET
>> @Path("bar")
>> public Bar getBar() {}
>> }
>>
>> Is it correct that a "GET /bar/" request won't be bound to getBar() ?
>>
>> According to the 2.5 section, the trailing '/' in GET request will
>> end up in the final matching group, when matching it against
>> Path("bar"), and thus according to 2.5.2.d, getBar() won't be included
>> in the list of candidates...
>>
>> Did I get it wrong ?
>>
>> Thanks, Sergey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland