Hi Peter,
Note that it has always been 'a hole' in that there can be sub-resources
used with sub-locators that are not annotated with URI template.
Peter Liu wrote:
> Yes, looking for @HttpMethod annotation in the class is definitely
> possible although less efficient.
True, but the code ain't complex for tooling support:
for (Method m : clazz.getMethods())
if (m.isAnnotationPresent(HttpMethod.class) ||
m.isAnnotationPresent(UriTemplate.class)) return true;
return false;
> 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.
>
A fair point, but tools can help :-) I think the previous solution of
using a '/' to distinguish root resource classes from resource classes
was very fragile and could easily introduce bugs with infuriated
developers wondering why things do not work because they forgot to use a
'/'. So if we need some form of identification of a resource class i
think it will have to be something more specific than 'UriTemplate'.
A resource class can also inherit from another resource class:
@UriTemplate("foo")
class FooResource { }
class ExtendedFooResource extends FooResource { }
So potentially this may not be obvious either.
Marc, i think we have a bug because we currently define UriTemplate to
be @Inherited. But this will cause a conflict for root resource classes.
Paul.
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109