Paul Sandoz wrote:
> 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;
>
>
For us, it is a bit more complicated since we are working with source
files and we have to use our complicated
Retouche java source api :-)
>> 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.
>
I agree your suggestion in the other reply regarding showing this
graphically using nodes. Other people have asked for this and we
haven't had the time to implement it. I guess this would be the impetus
for us to implement it.
>
> 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
>>
>