Hi,
note that a bean can often be declared and injected based solely on its interface. In such case, CDI specification declares certain inheritance rules[1] one of which is that you don't inherit from interfaces. That would break your model plus in then incentivises use of some concrete implementation class instead of interfaces and/or abstractions.
Other issue I can see is that in a complex bean class hierarchy you can override methods, inherit and not inherit (based on presence of `@Inherited`) some or all of their annotations which then ends up heavily affecting the resolution process for your proposal. It also requires a deep preliminary knowledge of existing classes to even make use of this approach which, to me personally, seems counterintuitive/counterproductive.
Not to mention that it introduces a (for instance) question of whether a bean is eligible for injection if it doesn't have given annotation on its method, but its predecessor does.
Last but not least, this change would basically affect the whole resolution model changing the bean definition from {Set<Type>, Set<Qualifier>} to something akin to {Set<Type>, Set<Qualifier>, Map<Method, Qualifier>} which is a lot more complex for seemingly no gain. So I am -1 for this.
> However, not rarely we need to find beans with annotations on methods and/or methods with a type
This doesn't feel like a good match for what CDI does and I honestly haven't seen that used until now. In theory, you could achieve this with existing model by iterating over all instances of given type and qualifiers or just starting from BM#getBeans() from you can inspect?
Matej
__________________________________________________________________________________________________
