[cdi-dev] CDI and generics

[Arne Limburg]

OK, so shall I create a TCK issue for that?


Cheers,
Arne

Am 10.07.13 13:50 schrieb "Martin Kouba" unter <mkouba at redhat.com>:

>Hi Arne,
>
>I think so (except the required type is Baz<List<Qux>>) - there is no
>bean with assignable bean type for this IP (according to CDI 1.1 rules
>of course).
>
>Martin
>
>Dne 10.7.2013 13:16, Arne Limburg napsal(a):
>> Hi Martin,
>> 
>> So, which bean should be injected into
>> @Inject
>>     private Baz<List<T2>> t2BazList;
>> ?
>> 
>> Baz<T> is also not assignable to Baz<List<String>>, because List<String>
>> is also not assignable from Object.
>> 
>> 
>> Am I right, that the test should throw an
>>UnsatisfiedResolutionException?
>> 
>> Cheers,
>> Arne
>> 
>> Am 08.07.13 12:17 schrieb "Martin Kouba" unter <mkouba at redhat.com>:
>> 
>>> Re Arne's question:
>>> Yes, Baz is a managed bean and AmbiguousResolutionException should not
>>> be thrown because Qux is not a managed bean (doesn't have a public
>>> no-arg constructor).
>>>
>>> Re Marko's findings:
>>> Yes, the TCK assertions are not up to date and Baz<T> is not assignable
>>> to Baz<String>, because String is not assignable from Object (no bound
>>> is defined -> Object is assumed; see JSL 4.4). So I confirm a TCK
>>>issue.
>>>
>>> IMO this would deserve a proper cleanup...
>>>
>>> Martin
>>>
>>> Dne 8.7.2013 01:22, Marko Lukša napsal(a):
>>>> I'd say it's a bug. While Baz indeed is a managed bean, it shouldn't
>>>>be
>>>> injected into injection point with type Baz<String> nor
>>>>Baz<List<Qux>>.
>>>> So I believe you're right in saying that this test should fail with
>>>> UnsatisfiedResolutionException.
>>>>
>>>> There was a change made to the spec way back in 2010 (see [1]), but
>>>>the
>>>> TCK apparently wasn't updated then. I've filed an issue in the TCK
>>>>jira
>>>> [2].
>>>>
>>>> The problem isn't only in the TCK, but also in the spec itself. Some
>>>>of
>>>> the examples in section 5.2.4 don't conform to the rules defined in
>>>>the
>>>> same section (according to the rules, bean Dao<T extends Persistent>
>>>> shouldn't be eligible for injection into Dao<Order> or Dao<User>). I
>>>> remember asking about this a year ago ([3]), but I didn't articulate
>>>>the
>>>> problem properly.
>>>>
>>>> [1]
>>>>
>>>> 
>>>>https://github.com/cdi-spec/cdi/commit/b32243350ace6a0bba337f91a35f5fd0
>>>>5c
>>>> 151f14
>>>> [2] https://issues.jboss.org/browse/CDITCK-349
>>>> [3] http://lists.jboss.org/pipermail/cdi-dev/2012-April/001742.html
>>>>
>>>> Marko
>>>>
>>>> On 7.7.2013 16:04, Arne Limburg wrote:
>>>>> Hi all,
>>>>>
>>>>> At the OpenWebBeans list we are currently discussing handling of
>>>>> generics in CDI.
>>>>> I found a test in the CDI 1.1 TCK, which imho has a bug. The test
>>>>> is 
>>>>> 
>>>>>org.jboss.cdi.tck.tests.inheritance.generics.MemberLevelInheritanceTes
>>>>>t
>>>>> and the (simplified) deployment scenario is the following:
>>>>>
>>>>> public class Baz<T> {
>>>>> }
>>>>>
>>>>> public class Qux extends Baz<String> {
>>>>> }
>>>>>
>>>>> @Vetoed
>>>>> public class Bar<T1, T2> {
>>>>>   @Inject
>>>>>   private Baz<T1> baz;
>>>>>   @Inject
>>>>>   private Baz<List<T2>> t2BazList;
>>>>> }
>>>>>
>>>>> @RequestScoped
>>>>> public class Foo extends Bar<String, Qux> {
>>>>> }
>>>>>
>>>>> public class Producer {
>>>>>   @Produces
>>>>>   @Amazing
>>>>>   public String produceString() {
>>>>>     return "ok";
>>>>>   }
>>>>>
>>>>>   @Produces
>>>>>   public String[] produceStringArray() {
>>>>>     return new String[0];
>>>>>   }
>>>>>
>>>>>   @Produces
>>>>>   public Baz<Baz<Qux>> produceBazBazQux() {
>>>>>     return new Baz();
>>>>>   }
>>>>> }
>>>>>
>>>>> The class Bar has some more injection points, but that does not
>>>>>matter.
>>>>> Due to the TCK this deployment should work, but I don't know how.
>>>>> Question: Is Baz a Bean (I suppose so) and may it be injected into
>>>>> Bean Foo, more precisely into the second injection point of class
>>>>>Bar?
>>>>> - If yes, it also should be injected into the first injection
>>>>> point, right? This would lead to an AmbiguousResolutionException
>>>>>since
>>>>> Qux may also be injected into the first injection point.
>>>>> - If no, the deployment should fail with a
>>>>> UnsatisfiedResolutionException since there is no Bean that can be
>>>>> injected into that injection point.
>>>>>
>>>>> Is this a bug in the TCK and if not, how is this supposed to work?
>>>>>
>>>>> Cheers,
>>>>> Arne
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>