[
https://issues.apache.org/jira/browse/CXF-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805243#comment-13805243
]
Ivan Bondarenko edited comment on CXF-5360 at 10/25/13 11:55 AM:
-----------------------------------------------------------------
Played a bit with org.apache.cxf.jaxrs.ext.ResourceComparator and looks like it
doesn't solve our problems. We want to check every class with
JAXRSUtils.findTargetMethod (and maybe some other methods) in
ResourceComparator, however:
1) ResourceComparator methods doesn't receive (as arguments or other way) the
information already gathered, first off all these variables: 'httpMethod',
'values', 'requestContentType', 'acceptContentTypes'. We must rewrite almost
whole
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(Message) for
getting them again.
2) To get 'values' variable, we must call
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(List<ClassResourceInfo>,
String, MultivaluedMap<String, String>, Message), which will create Comparator
again and enter it, so this is an infinite stack loop. Or we must rewrite this
method also.
I think by default CXF should check every resource-class whether it is really
fits the request by all data, not only by path.
was (Author: buzzeri):
Played a bit with org.apache.cxf.jaxrs.ext.ResourceComparator and looks like it
doesn't solve our problems. We want to check every class with
JAXRSUtils.findTargetMethod (and maybe some other methods) in
ResourceComparator, however:
1) ResourceComparator methods doesn't receive (as arguments or other way) the
information already gathered, first off all these variables: 'httpMethod',
'values', 'requestContentType', 'acceptContentTypes'. We must rewrite almost
whole
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(Message) for
getting them again.
2) To get 'values', we must call
org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(List<ClassResourceInfo>,
String, MultivaluedMap<String, String>, Message), which will Create Comparator
again and enter it, so this is an infinite stack loop. Or we must rewrite this
method also.
I think by default CXF should check every resource-class whether it is really
fits the request by all data, not only by path.
> Resource classes are selected incorrectly
> -----------------------------------------
>
> Key: CXF-5360
> URL: https://issues.apache.org/jira/browse/CXF-5360
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.7.7
> Reporter: Ivan Bondarenko
> Priority: Blocker
>
> The problem: the resource is selected incorrectly when multiple classes can
> 'visually' handle request. For example if we have two classes
> @Path("/") class Foo {
> @GET @Path("bar") public String bar() { return "bar"; }
> }
> @Path("/") class Real {
> @GET @Path("hello") public String hello() { return "hello"; }
> }
> and their instances are registered in this order (e.g. in
> jaxrs:serviceBeans), when I GET the "/hello" path, the Foo will be selected,
> while it is not even able to handle this request.
> The starting point to investigate the problem is
> org.apache.cxf.jaxrs.utils.JAXRSUtils.selectResourceClass(List<ClassResourceInfo>,
> String, MultivaluedMap<String, String>, Message), where 'candidateList'
> variable is filled incorrectly. Unfortunately I'm not so familiar with CXF
> code to provide a patch, but resource class must be selected basing on full
> class description (all methods and annotations must be taken into account).
> Why this is a problem: except obvious reason (unexpected behavior), this bug
> disallows to make REST service modular. For example we may want to provide
> different feature sets for different servers. Right now it is not possible to
> implement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
