New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuration processor does not handle generics #15850
Comments
Yes, you're right, the annotation processor should be able to resolve Would it be possible to simplify that arrangement to avoid the generics? We prefer that Flagging for team attention to see what the rest of the team thinks. |
@snicoll we did put a fix in place, it works but it's pretty ugly. |
I agree that it might be hard to fix (especially for all corner cases), but I was surprised to see that overriding the getter with the explicit return type didn't work either... @ConfigurationProperties("foo.bar")
public class GenericProperties extends AbstractPropeties<Foo> {
@Override
public Map<String, Foo> getProps() {
return super.getProps();
}
} We still get (I tried overriding both the getter and setter with the same result). Perhaps a reasonable compromise would be to at least make this work? |
Method method = ClassUtils.getMostSpecificMethod(
ClassUtils.getMethod(GenericProperties.class, "getProps", new Class[0]), GenericProperties.class);
Type returnType = method.getGenericReturnType();
System.out.println(returnType);
|
It's easy for me to say as I don't know how hard it is to implement, but when I first saw the discussion on Slack my reaction was that this is something that we should support. That's still my view now so I'd like us to take a look at what it would entail. |
Given
and
The generated metadata is
Should be
The generator should be able to determine the generic type.
Per Kris De Volder in Slack
See spring-cloud/spring-cloud-stream#1601
The text was updated successfully, but these errors were encountered: