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