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

From: Bill Burke <>
Date: Mon, 12 Oct 2015 08:52:19 -0400

Both are reg exp. The @Path - reg ex is probably more specific than the
<path param>, so the regex would be picked. Read the spec, you have to
count characters in the expressions. path param has none.

On 10/11/2015 3:28 AM, Markus KARG wrote:
> Experts,
> 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 claim.
> 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 **_at_GET
> @Path(//<PathParam>/) and **_at_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
> questions:
> (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. :-)
> Thanks
> -Markus

Bill Burke
JBoss, a division of Red Hat