Hi
> They way things are specified is that a root resource class requires
> that a URI path context is associated with it so that path matching can
> be performed on that root resource class. @Path declares that context.
> Do you want to use something other than @Path to specify the URI path
> context when registering root resource classes?
No, not really. I was just thinking that both root resource classes and those representing
sublocators are the same from the processing point of view. For ex, a subresource locator may be missing a
@Path annotation, thus it's ok to assume it actually has @Path("/"), and it works. Same for a root resource.
> For example Jersey scans for @Path on classes and automatically
> registers them and the developer does not have do any configuration.
How does does it distinguish between root resources and those representing subresources, as all of them can have @Path ?
Perhaps doing some advanced code analysis can help with selecting the right class as a root resource one...
>
>> Having default values even for root resource
>> classes also simplifies the implementation a bit,
>
> Not sure i understand. Can you provide an example?
I'm just assuming that all resource classes have @Path annotations, either explicit ones or default Path("/") ones..
Thus I don't need to check if it's a root resource and it contains no @Path then it's an error...
Thanks, Sergey
>
> Paul.
>
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland