We do deal with @DefaultValue the way the spec says, but again, we still
barf if you try to use @PathParam on a field of a singleton. This is
because the code we use to do injection is completely generic and
doesn't care whether its injecting into a setter method, field, or
parameter. The SPI also has a strict contract for injecting into a
singleton vs. a per-request object.
On 2/23/12 1:07 PM, Marek Potociar wrote:
> Interesting. How do you deal with @DefaultValue ? Do you allow it for @PathParam?
>
> Marek
>
> On 02/23/2012 06:20 PM, Bill Burke wrote:
>> Really depends on the lifecycle of the object. Resteasy we barf if you try to do this with a singleton, but allow it
>> (and return "baz") for per-request scoped resource classes.
>>
>> On 2/23/12 6:01 AM, Marek Potociar wrote:
>>> Hello experts,
>>>
>>> we've received a bug report in Jersey about the following use case:
>>>
>>> @Path("foo")
>>> public class FooResource {
>>> @PathParam("id") String id;
>>>
>>> @GET
>>> @Path("bar/{id}")
>>> public String get() {
>>> return id;
>>> }
>>> }
>>>
>>> My question is, given the "id" path template is defined on a sub-resource method, should the value still be injectable
>>> into the resource field or not?
>>>
>>> IOW, with the example above, what should be a result of GET "/foo/bar/baz" request? Should it be "baz" or null ?
>>>
>>> Thanks,
>>> Marek
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com