[jax-rs-spec users] _at_Path with regular expression overrides other @Path's with the same URI

From: Markus KARG <>
Date: Sun, 11 Oct 2015 09:28:24 +0200



in a discussion on the Jersey user group someone claimed that the behaviour
of Jersey is different from CXF and RestEasy. As that would imply both, an
inaccuracy of the TCK (it does not detect the deviation) and a violation of
the specification in CXF and RestEasy (as Jersey is the RI, hence
axiomatically cannot be wrong), we should quickly clarify the truth in that



The case is recorded in Jersey's issue tracker including source code
( and is simple to explain:


Given a resource has two methods, annotated as @GET @Path(/<PathParam>) and
@DELETE @Path(/<RegEx>)

When a client invokes GET <RootURI>/<PathParam> upon that resource

Then the result is 405 Method Not Allowed


While this looks pretty odd to the average Joe (as there is a perfect match
of GET and <PathParam>), it was claimed that this is compliant to the
specification (since regex have higher priority than literals, and methods
are matched after URIs).


It was reported that CXF and RestEasy return 200 OK instead, while the RI
does return 405 Method Not Allowed.


Certainly an application MUST return the same status code on ANY JAX-RS
compliant implementations, so we should clarify ASAP the following


(1) @SpecLeads: Is the use case described above (regex beats literals)
really compliant to the JAX-RS specification, and how to explain to the
average Joe the reasonability of ignoring the apparently perfect match?


(2) @SpecLeads: Is there a bug in the TCK so it does not detect the
deviation of CXF and RestEasy?


(3) @Vendors: Can you please check your implementations whether they really
violate the spec? Do you have plans to fix it?



I think we all have a vital interest in clarifying it, as a standard makes
only sense when it is reasonable and commonly accepted, so I would be glad
if you could answer the above points rather soon. :-)