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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev