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.