Another point is that sub-resource classes are forced to use @HttpMethod
annotations, whereas top resource classes could just have the
@HttpMethod implied by method name prefixes like "get". This kind of
inconsistence could be potential confusion for the API.
IMHO, it would be much simpler if we have explicit resource declaration
with marker annotation like
@WebResource(uriTemplate="a")
class MyResource {
// sub-locator method
@SubResource(uriTemplate="b")
public MySubResource getMySubResource(...) {
// Life-cycle is per-request
return new MySubResource(...);
}
}
}
@WebResource
class MySubResource {
public MySubResource(...) { ... }
}
}
This explicitness would be easier for both developers and tools.
-Nam
Peter Liu wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>