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/b32243350ace6a0bba337f91a35f5fd05c...
[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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev