Bug 1156645

After a few debugging and analysis, I found that the issue is in Types class. A utility class to find more about the actual type of a given parameter.

At the MethodInjectorImpl class, we have the type retrieving:

      Type[] genericParameterTypes = actualMethod.getGenericParameterTypes();
      for (int i = 0; i < actualMethod.getParameterTypes().length; i++)
      {
         Class<?> type;
         Type genericType;

         // the parameter type might be a type variable defined in a superclass
         if (actualMethod.getGenericParameterTypes()[i] instanceof TypeVariable<?>)
         {
            // try to find out the value of the type variable
            genericType = Types.getActualValueOfTypeVariable(root, (TypeVariable<?>) genericParameterTypes[i]);
            type = Types.getRawType(genericType);
         }
         else
         {
            type = actualMethod.getParameterTypes()[i];
            genericType = genericParameterTypes[i];
         }

         Annotation[] annotations = method.getParameterAnnotations()[i];
         params[i] = factory.getInjectorFactory().createParameterExtractor(root, method, type, genericType, annotations);
      }


And at the following line is were we can observe the bug:

            // try to find out the value of the type variable
            genericType = Types.getActualValueOfTypeVariable(root, (TypeVariable<?>) genericParameterTypes[i]);

For the class that works, it will return the correct type of the class. For the class that is not working, it returns the type TypeVariable, leading to the mentioned error.

Now, the question is why it works with JSON? I believe that the answer is how the MessageBodyReader from jackson implemented the isReadable method.

The JAXB implementation is as follow:


      return type.isAnnotationPresent(XmlRootElement.class) && (FindAnnotation.findAnnotation(type, annotations, DoNotUseJAXBProvider.class) == null) && !IgnoredMediaTypes.ignored(type, annotations, mediaType);


It means that it trusts on the type that was passed. 


After this debugging, I went to upstream source to see how is they type retrieved, since the fix could be on the type retrieving because the MessageBodyReader for JAXB didn't change its isReadable implementation. The problem is that the Types class changed a lot:

https://github.com/resteasy/Resteasy/blob/master/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/util/Types.java


Probably due some spec change, since upstream resteasy implements JAX-RS 2.0. Basically I meant that we don't have the fix yet. The fix will probably be change the method Types.getActualValueOfTypeVariable to make it works with the ConcreteResource scenario and return the correct type.

Weinan Li <weli> updated the status of jira RESTEASY-1125 to Resolved

Setting to MODIFIED from the following mail thread:
- - - -
Yes they are all included.

--
Weinan Li / JBoss

On Nov 20, 2014, at 8:44 PM, Kabir Khan <kabir.khan> wrote:

Are either https://bugzilla.redhat.com/show_bug.cgi?id=1156645 or https://bugzilla.redhat.com/show_bug.cgi?id=1165332 fixed by today’s RestEasy upgrade https://bugzilla.redhat.com/show_bug.cgi?id=1118891?

Verified in EAP 6.4.0.DR11 with RESTEASY-1125 test.