[cdi-dev] CDI and generics

[Mark Struberg]

Another question:

A producer for @Dependent Baz<T> could theoretically inspect the InjectionPoint and create the right thing.
Not sure if this is worth the hassle, just like to point it out.


LieGrue,
strub



----- Original Message -----
From: Martin Kouba <mkouba at redhat.com>
To: Marko Lukša <marko.luksa at gmail.com>
Cc: cdi-dev at lists.jboss.org
Sent: Monday, 8 July 2013, 12:17
Subject: Re: [cdi-dev] CDI and generics

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/b32243350ace6a0bba337f91a35f5fd05c151f14
> [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.MemberLevelInheritanceTest
>> 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