[jax-rs-spec users] [jsr339-experts] Re: Re: Allowing two resources to be mapped to the same URI

From: Marek Potociar <>
Date: Tue, 22 May 2012 11:28:21 +0200

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.

> I can also see the following:
> @Path("/{options : .*}")
> public class HandleOptionsGenerically
> {
> 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.

> 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.

FWIW, the first use case would be easily supportable in Jersey too. It however promotes bad design practices and has a negative impact on the code readability and maintainability. It's OK to have such support in implementations but we should not put it into the spec.
The second use case requires back-tracking in matching and thus would not be supported by Jersey at the moment without modifications. OTOH Jersey does support automatic HEAD and OPTIONS processing via internal filtering mechanisms. Filters in general are much more elegant solution for this type of use cases compared to the solution suggested above.


> On 5/21/12 4:07 PM, Marek Potociar wrote:
>> Hello experts,
>> please have a look at the issue
>> and share your opinion. I am
>> proposing to close as "won't fix" for the reasons explain in my comment
>> to the issue.
>> Unless there are objections I'm going to close the issue by the end of
>> the week.
>> Marek
> --
> Bill Burke
> JBoss, a division of Red Hat