[
https://issues.apache.org/jira/browse/CXF-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-5650:
----------------------------------
Summary: JAX-RS runtime needs to exclude matching sub-resources by default
if matching resource methods exist (was: JAX-RS client runtime needs to
exclude matching sub-resources by default if matching resource methods exist)
> JAX-RS runtime needs to exclude matching sub-resources by default if matching
> resource methods exist
> ----------------------------------------------------------------------------------------------------
>
> Key: CXF-5650
> URL: https://issues.apache.org/jira/browse/CXF-5650
> Project: CXF
> Issue Type: Task
> Components: JAX-RS
> Reporter: Sergey Beryozkin
> Assignee: Sergey Beryozkin
> Fix For: 3.0.0
>
>
> Consider the request "GET /root/book" and the following code:
> {code:java}
> @Path("root")
> public class Root {
> @Path("book")
> public getSub() {return new Sub();}
> @Path("book")
> @POST
> public void addBook(Book book) {}
> }
> public class Sub {
> @GET
> public Book getBook() {}
> }
> {code}
> CXF will dispatch the call to Sub.getBook().
> Unfortunately, JAX-RS matching algorithm is currently written such that the
> call will rejected due to the fact the matching sub-resource is supposed to
> immediately discarded if the current root has methods matching the same path,
> even though these methods (such as addBook) has no matching HTTP verb.
> IMHO it is a JAX-RS algorithm limitation and I'm positive at the moment that
> this issue will be addressed as part of the JAX-RS 2.1 work. However CXF
> needs to support this behaviour *by default* for CXF to stay on the 'pure'
> JAX-RS 2.0 path.
> The contextual property to support the users depending on the current CXF
> approach will be introduced
--
This message was sent by Atlassian JIRA
(v6.2#6252)
