cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Shvid (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6078) AnnotationUtils.getAnnotatedMethod for abstract classes not inherit from interface
Date Tue, 04 Nov 2014 17:07:34 GMT

    [ https://issues.apache.org/jira/browse/CXF-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196363#comment-14196363
] 

Alexander Shvid commented on CXF-6078:
--------------------------------------

I already wrote

"For me, this bug leads to the situation that not all methods are having mapping in the application."
That means that AnnotationUtils.getAnnotatedMethod skips some method declarations that are
fully legal by JAX-RS specification. In this current test 'set' method is fully legal and
it was skipped.




> AnnotationUtils.getAnnotatedMethod for abstract classes not inherit from interface
> ----------------------------------------------------------------------------------
>
>                 Key: CXF-6078
>                 URL: https://issues.apache.org/jira/browse/CXF-6078
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.7.13
>            Reporter: Alexander Shvid
>         Attachments: AbstractNameServiceImpl.java, AnnotationUtilsTest.java, NameService.java,
NameServiceImpl.java
>
>
> I created the special junit test to demonstrate this bug.
> Suppose we have NameService with annotated methods: 'get' and 'set'.
> NameServiceImpl that implements NameService and only 'get' method.
> AbstractNameServiceImpl that implements 'set' method. 
> NameServiceImpl extends AbstractNameServiceImpl.
> AbstractNameServiceImpl does not implement NameService.
> For this case AnnotationUtils.getAnnotatedMethod returns wrong annotatedMethod for 'set'.
It is actually same method as requested one, but not the 'set' method from the interface.
> m = public javax.ws.rs.core.Response NameServiceImpl.get(java.lang.String)
> a = public abstract javax.ws.rs.core.Response NameService.get(java.lang.String)
> m = public javax.ws.rs.core.Response AbstractNameServiceImpl.set(java.lang.String)
> a = public javax.ws.rs.core.Response AbstractNameServiceImpl.set(java.lang.String)
> JDK1.7.0_51
> It happens because AnnotationUtils.getAnnotatedMethod has only single argument Method,
that is the method 'set' from super class AbstractNameServiceImpl. It does not have information
about NameServiceImpl itself and does not check hierarchy of the NameServiceImpl as well.
In fact, logically it checks superclass AbstractNameServiceImpl only, but really we are using
NameServiceImpl as a service class. This is the bug.
> Solution:
> AnnotationUtils.getAnnotatedMethod needs additional Class<?> serviceClass argument
to check hierarchy of service class to find annotated method, that's because Method argument
can be from any level of super class of the serviceClass and there is no guarantee that it
implements base RESTful interface with annotated methods.
> It actually affects ResourceUtils.createClassResourceInfo
> that calls AnnotationUtils.getAnnotatedMethod to detect annotated method in the loop
>     private static void evaluateResourceClass(ClassResourceInfo cri, boolean enableStatic)
{
>         MethodDispatcher md = new MethodDispatcher();
>         for (Method m : cri.getServiceClass().getMethods()) {
>             
>             Method annotatedMethod = AnnotationUtils.getAnnotatedMethod(m);
> It knows about ServiceClass, but does not use this information to walk in classes hierarchy.
> For me, this bug leads to the situation that not all methods have mapping in the application.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message