Use of `java.lang.reflect.Type` not sufficient for proper generic types about feign HOT 8 CLOSED

thx @cowtowncoder. Note that this is a bit theoretical until you attach a failing test case :)

feign is only relevant for fully resolved (read not parameterized) defined java interfaces. These methods can and do have parameterized method return vals. The types used in Decoder, for example, are captured using feign.Types.

You'll notice that these Type objects are properly parsed by feign-sax (home grown) and feign-gson. Internally at netflix, we also have a jackson module, which we can also post.

So... while things are working, I'm not sure what to do with this issue :)

from feign.

closing until this becomes an issue.

from feign.

I don't yet have a personal use case, so let me to try to explain a problem I see from API perspective.

How am I to specify that results should be, say, List of UUIDs? (List<UUID>)?

Or parameterized response object like Response<UserOperation<Addition>>?

I am looking at this from module implementor's perspective, but same issue exist from user perspective: you can pass a Class<?>, but those are type-erased.

Alternative you can of course say that Feign only supports binding to/from non-generic POJOs. If so, that is an acceptable limitation (to me), and makes it clear that generics are not supported for root values.

from feign.

It isn't expected or supported for someone to use Decoder outside of feign. When Feign calls Decoder.decode(Response, Type), a proper type is passed as an argument or else decoders like our gson one would never work. If you look at denominator, or the test cases, you'll notice parameterized types are used, for example. This is why I'm saying this is theoretical until the issue raises a valid limitation.

The decoder's responsibility is to use this type object to, for example, construct its own type token as necessary. If the implementation cannot do that, then that's a limitation of the implementation. When I used jackson, I had to use the type token factory thing to create one from the type passed to Decoder. If you still have trouble, I can dig that up.

from feign.

Easiest way to complete this task w/o getting into abstract type discussion is to copy paste this and revise it slightly to match feign interface def

https://github.com/square/retrofit/blob/master/retrofit-converters/jackson/src/main/java/retrofit/converter/JacksonConverter.java

from feign.

p.s. if you are interested in how the type passed to decoder.decode is constructed, here's the sequence.

Some subtype of feign.Contract processes the method defined on the interface being processed.
This sets MethodMetadata.returnType(method.getGenericReturnType())
This metadata is held constant for all invocations of the decoder.

If someone wanted to unit test the decoder behavior, they'd want to either save a generic type off using TypeToken, or make a static inner interface in the test class and pull method.getGenericReturnType(), or something more fancy :)

HTH

from feign.

hopefully this helps..

eb03e20

from feign.

Ok thank you. This does make more sense, wrt. what users can pass. The problem is then more limited, and I agree it is not of immediate concern. So this can be reopened if it becomes an actual problem.

I still think that use of Type often leads to problems (the reason I submitted this was because it is common problem case for Jersey, FWIW), but it is true that problem is contextual: passing Type from method return value or Field is always problematic, if type has type variables that are bound by class; whereas passing Type that is parameterization of a "type token" is not (since it defines type at class level where all information is indeed available).

Thank you for taking time to check this out and explain flow of type information through Feign.

from feign.