Bill,
no I did not miss that example. But -as many specs do- I assume that
examples are non-normative but solely illustrative.
Actually neither the spec nor the JavaDocs explicitly say that root
resources MUST have @Path. In fact, Jersey deploys a root resource
WITHOUT having @Path. That's the actual reason why I am asking: What
DOES Jersey do in that case (it does NOT complain at least), and how
MUST a JAX-RS implementation deal with @Path-free root resources?
In fact I don't understand why we cannot simply add a short line to
the spec instead of discussion: "An un-annotated root resource class
MUST be treated as if @Path("") would be existing at the class". That
would be unambiguously make clear how Jersey, RestEasy and CXF MUST
deal with that case.
-Markus
Zitat von Bill Burke <bburke_at_redhat.com>:
> FYI: Root resource classes require a class level @Path annotation.
> Maybe you missed the end of the Javadoc where it gives
> http://example.com/catalogue/widgets and
> http://example.com/catalogue/widgets/nnn as an example?
>
> On 2/29/2016 1:46 PM, markus_at_headcrashing.eu wrote:
>> Bill,
>>
>> no need to imply that I did not read the Javadocs -- I did several
>> times before asking.
>>
>> Here is the full JavaDoc of @Path annotation as of v2.0. Please
>> tell me where it says what Jersey will do in case no @Path is found
>> anywhere in a JAX-RS resource class (yes, it talks about base URIs,
>> but it does not say that the default for the annotation's value
>> must be "/" or "" which is possibly what you imply and which is NOT
>> what Jersey does). BTW, it DOES need explanation as I was asked
>> that very question several times, so it is everything but
>> unambiguous for others:
>>
>> @Target(value={TYPE,METHOD})
>> @Retention(value=RUNTIME)
>> @Documented
>> public @interface Path
>> Identifies the URI path that a resource class or class method will
>> serve requests for.
>> Paths are relative. For an annotated class the base URI is the
>> application path, see ApplicationPath. For an annotated method the
>> base URI is the effective URI of the containing class. For the
>> purposes of absolutizing a path against the base URI , a leading
>> '/' in a path is ignored and base URIs are treated as if they ended
>> in '/'. E.g.:
>>
>> @Path("widgets")
>> public class WidgetsResource {
>> @GET
>> String getList() {...}
>>
>> @GET @Path("{id}")
>> String getWidget(@PathParam("id") String id) {...}
>> }
>> In the above, if the application path is catalogue and the
>> application is deployed at http://example.com/, then GET requests
>> for http://example.com/catalogue/widgets will be handled by the
>> getList method while requests for
>> http://example.com/catalogue/widgets/nnn (where nnn is some value)
>> will be handled by the getWidget method. The same would apply if
>> the value of either @Path annotation started with '/'.
>>
>> Classes and methods may also be annotated with Consumes and
>> Produces to filter the requests they will receive.
>>
>> -Markus
>>
>>> Go read the Javadoc for @Path. It is explained there and IMO,
>>> needs no further explanation.
>>>
>>>
>>> On 2/29/2016 12:32 PM, markus_at_headcrashing.eu wrote:
>>>> According to the current wording of the JAX-RS 2.0 specification,
>>>> a compliant JAX-RS resource class not necessarily must have a
>>>> @Path annotation (it is enough to have @GET for example). Maybe I
>>>> am blind, but I cannot see an explanation what the default path
>>>> shall be in case no @Path is found. So my question is:
>>>>
>>>> How do Jersey / CXF / RestEasy handle this case currently, and
>>>> won't it be a good idea if we add a short note to the JAX-RS 2.1
>>>> spec how it SHALL be like?
>>>>
>>>> -Markus
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com