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.
>