On Jan 11, 2008, at 9:01 AM, Stephan Koops wrote:
>> Multiple possible methods / root resource classes for one request
>> in the algorithm for matching requests to resource methods, part 1e
>> does not define what happens, when multiple root resource classes
>> have the same @Path annotation. The same is in part 2 f/g and 3b/c.
>> Is it implementation dependent, like the choose of the constructor,
>> if there are more valid constructors (all parameters correct
>> annotated and with the same no of parameters?) Or must the runtime
>> environment generates error status 500?
> for Part 3b/c another problem: We have multiple resource methods for
> the same Path, producing different Mime-Types, "text/html" and "text/
> plain", for example.
> In a request they are both accepted with the same quality (or "text/
> *" was requested). What should happens? I think it is not a good
> idea to reject the request as not acceptable, as internal error or
> what ever.
>
> In @ProduceMime it is not possible to specify a method to prefer. A
> possibility is to add an attribute ("preference" for example, a
> numeric type), where the runtime environment choose the method with
> the highest (or lowest) preference, if the
>
> If we don't want to complicate the API, the implementation should be
> allowed to use anyone of the methods. That's ok I think, because the
> client allows this in the request.
>
I think the above is the current behavior according to 3c, i.e. M
would have multiple entries and 3c would pick one. It bothers me that
different implementations could pick different methods but I don't see
how we could get round that - even if we added a "preference" param
you could end up with two methods with the same value of that and I
don't think we can use lexical order since Class.getMethods doesn't
guarantee any particular order.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.