I'm emailing directly because I cannot post to the list... I am lurking
Marc Hadley 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 implementation generates error
>> status 500?
>> BTW: To the illustrated case you can say, that the developer should be
>> more intelligent, but another tricky case with the same problem are
>> two classes or methods annotated with @Path("abc/{var}") and
>> @Path("{var}/def") called with URI "http://.../.../abc/def"
>>
> You raise a tricky issue, it seems to me that generating an error would
> be the right thing to do. Unless someone has a better idea for how to
> pick amongst the alternatives ?
>
No error. The way I've implemented it was
http://.../abc/def tries to match the more explicit mapping
(@Path("abc/{var")) first before trying to match wildcards.
The usecase for this is that you have a wildcard that provides default
behavior and individual exceptions to the default are provided ad hoc.
> See issue 5:
>
I really think you should mind-meld with the Java EE groups. EE in
general needs an abstract interface for security context that can be
used with EJB, Servlet, etc, in a common manner.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com