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