On 5/22/12 5:28 AM, Marek Potociar wrote:
>
> On May 21, 2012, at 10:35 PM, Bill Burke wrote:
>
>> I can see users wanting to add support for different formats in different resource classes. i.e.
>>
>> @Path("/root")
>> @Produces("application/xml")
>> public class MyRootXmlSupport {}
>>
>> @Path("/root")
>> @Produces("application/json")
>> public class MyJsonSupport {}
>>
>
> One of the main design concepts behind JAX-RS is that it should produce a representation independent model. The above use case just seems artificial to me and goes against the intended best practices.
>
Whose best practices are you talking about? Its definitely not a bad
practice, especially if there any media type formatting specific logic.
Especially if your JAX-RS services are just a face over some EJB you
are delegating to.
>>
>> I can also see the following:
>>
>> @Path("/{options : .*}")
>> public class HandleOptionsGenerically
>> {
>> @OPTIONS
>> public Response handleOptions() {...}
>> }
>>
>
> That one requires IMO changing the matching algorithm to support full back-tracking, which would make the matching very inefficient. To put it clearly, I am not going to support any change request that would require introduction of back-tracking into the matching algorithm.
>
Well, in resteasy we do a recursive depth first search on a tree of
mapped resource methods. Locators are always matched after static and
expression-based paths are evaluated. We don't backtrack on locators.
>>
>> BTW, I didn't even know this restriction existed and is something we already do by default in resteasy. I don't see why it is a big deal to support/allow.
>
> See my reasoning above.
>
I think your reasoning is flawed. I don't see how 2 classes with the
same @Path expression is any different from 2 methods with the same
@Path expression. Matching should be based on resource methods, not
resource class except for the case of a sub-locator.
BTW, if you guys ever add a TCK test for this, I think there would be at
least a few pissed off users.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com