cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-5650) JAX-RS runtime needs to exclude matching sub-resources by default if matching resource methods exist
Date Wed, 26 Mar 2014 10:16:18 GMT

     [ https://issues.apache.org/jira/browse/CXF-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sergey Beryozkin updated CXF-5650:
----------------------------------

    Description: 
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 be 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




  was:
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





> 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
be 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)

Mime
View raw message