Community
Participate
Working Groups
Created attachment 191824 [details] Sample JUnit In order to inject a value from a context using class type matching, the types must match exactly. We won't inject a subtype. This gets somewhat problematic for generics. While "@Named" works well, injection using type matching will require exact match between the type description in the context and type being injected. Attached is a sample JUnit that demonstrates the issue. I am not sure if it is possible to provide such matching without incurring significant performance overhead. I am opening this bug both to have the record is this issue and in case anybody has an idea on how such matching can be implemented in a reasonably efficient form.
Created attachment 191999 [details] Sample JUnit 2 This is the problem I was seeing. I don't think it is the same problem as the one you have in your attachment 191824 [details], Oleg.
(In reply to comment #1) > This is the problem I was seeing. I don't think it is the same problem as the > one you have in your attachment 191824 [details], Oleg. Thanks for the sample! At the core, it is the same issue. Injection of generics using type matching is not implemented. It might be possible to force it work for a specific example (and it might seem to work for some examples thanks to our auto-create functionality) but basically, it is not supported at he moment.
Created attachment 192031 [details] Patch for key from descriptor - untested An untested patch that creates String description based on a parameterized type (generics). This patch is not meant to be applied "as is", this is just a note for future use. Note that the "other" side - the IEclipseContext#set() methods - would have to changed as passing "Class<>" won't work. Another approach could be to add something like type erasure making "ClassABC<Type XYZ>" treated like "ClassABC". That is doable, but feels unsafe.
Created attachment 198206 [details] Patch After some reflection on the subject - yes, let's use type erasures. Just like Java does, the "Feeder<Bird>" will be treated as "Feeder" when looking up unnamed matches in the context. Matching by type is inherently not safe, adding type erasures will only marginally influence that. And having type erasures mimics Java behavior eliminating the need to introduce some custom rules. (The JUnits are rolled into this patch.)
Patch applied to CVS Head.
