Yes, looking for @HttpMethod annotation in the class is definitely
possible although less efficient.
Another concern I have is that it become less obvious for developers to
tell if a class
is a resource class whereas before, it is much easier with the
@UriTemplate annotation
at the top of the file.
Peter
Marc Hadley wrote:
> With this change a resource class is any class that has at least one
> method annotated with @HttpMethod or @UriTemplate. Could the tooling
> look at the methods to determine if a class is a resource or not ?
>
> Marc.
>
> On Jul 11, 2007, at 5:12 PM, Peter Liu wrote:
>
>> Hi Paul,
>>
>> Please find my comments below. I think there might be some tooling
>> related issues
>> with this change.
>>
>> Thanks.
>>
>> Peter
>>
>> Paul Sandoz wrote:
>>> Peter Liu wrote:
>>>> Hi,
>>>>
>>>> In the upcoming 0.2 release, @SubResource annotation will be removed.
>>>> What is the replacement for it and could you provide some code snippet
>>>> that demonstrate the new approach?
>>>>
>>>
>>> Sure.
>>>
>>> Before:
>>>
>>> @UriTemplate("/a")
>>> @SubResources(MySubResource.class)
>>> class MyResource {
>>> }
>>>
>>> @UriTemplate("b")
>>> class MySubResource {
>>> }
>>>
>>>
>>> After:
>>>
>>> @UriTemplate("a")
>>> class MyResource {
>>>
>>> // sub-locator method
>>> @UriTemplate("b")
>>> public getMySubResource(...) {
>>> // Life-cycle is per-request
>>> return new MySubResource(...);
>>> }
>>> }
>>>
>>> class MySubResource {
>>> public MySubResource(...) { ... }
>>> }
>>>
>>>
>>> Points of note:
>>>
>>> - Removed the requirement that root resource classes have a URI
>>> template
>>> that starts with a '/'. Now any resource class annotated with a URI
>>> template is a root resource class and the URI template is relative to
>>> the base URI of deployment.
>>>
>>> - MySubResource can still be root resource class but when used as part
>>> of a sub-locator method the URI template on the class will be
>>> ignored.
>>>
>> Here is the issue I see with this. Currently, we rely on the
>> @UriTemplate
>> annotation to distinguish a REST resource from a plain Java class. (We
>> use this to enable REST related features in the IDE.)
>> With the removal of @SubResource and the change that allows any class
>> with an URI template to behave as a root resource class, the only way
>> I see for
>> keeping a resource from becoming a root resource is to not specify
>> any @UriTemplate annotation on the class. This is especially important
>> for the container-item pattern, since we don't want to expose the
>> item resource
>> as a root resource. However, by not specifying the @UriTemplate
>> annotation
>> on the subresource, we lose the ability to identify the class as a
>> REST resource class.
>> It looks like we need some other way such as a special annotation to
>> identify
>> a class as a REST resource class. Or, there should be an attribute
>> on @UriTemplate
>> that indicates a resource cannot be a root resource. What do you think?
>>
>>> - Injection currently does not work on objects returned by sub-locator
>>> methods (i.e. the same as it is today). The EG is having discussions
>>> on life-cycle and injection. Until these discussions reach a
>>> satisfactory conclusion we cannot do anything about this issue.
>>>
>>> Paul.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>