<p style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">+1, if we are no more aligned on something so simple in plain java we are useless i fear :(</p><p style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
(i used and saw it used in a lot of real apps)</p><p style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></p><div><div><i>Romain Manni-Bucau</i></div><div><i>Twitter: <a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a></i></div>
<div><i>Blog: </i><a href="http://rmannibucau.wordpress.com/" target="_blank"><i>http://rmannibucau.wordpress.com/</i></a></div><div><i>LinkedIn: </i><font color="#0000ee"><i><u><a href="http://fr.linkedin.com/in/rmannibucau" target="_blank">http://fr.linkedin.com/in/rmannibucau</a></u></i></font></div>
<div><i><span style="background-color:rgb(255,255,255)">Github: </span><a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a></i></div><div><br></div></div>
<br><br><div class="gmail_quote">2013/7/14 Mark Struberg <span dir="ltr"><<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
folks, this breaks backward compatibility<br>
<br>
<br>
In CDI 1.0 it was perfectly fine to do the following<br>
<br>
@Produces<br>
@Dependent<br>
public <KEY, VALUE extends Serializable> Cache<KEY, VALUE> getDefaultCache(InjectionPoint injectionPoint) {<br>
Type ipType = injectionPoint.getType();<br>
String cacheName = null;<br>
<br>
if (ipType instanceof ParameterizedType) {<br>
ParameterizedType generic = (ParameterizedType) ipType;<br>
Type[] paramTypes = generic.getActualTypeArguments();<br>
if (paramTypes == null || paramTypes.length != 2) {<br>
throw new RuntimeException("illegal param types for generic type " + ipType);<br>
}<br>
<br>
if (paramTypes[1] instanceof Class) {<br>
cacheName = ((Class) paramTypes[1]).getSimpleName();<br>
}<br>
else {<br>
cacheName = paramTypes[1].toString();<br>
}<br>
}<br>
<br>
return getCache(cacheName);<br>
}<br>
<br>
<br>
<br>
usage:<br>
<br>
<br>
@Inject<br>
private Cache<String, IdmUser> userCache;<br>
<br>
<br>
With your new interpretation you basically trash this, right?<br>
For having a generic producer you would need to create a distinct producer method for each and every usage. This just doesn't work out in practice...<br>
<div class="im HOEnZb"><br>
<br>
<br>
LieGrue,<br>
strub<br>
<br>
<br>
<br>
<br>
<br>
----- Original Message -----<br>
From: Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>><br>
</div><div class="im HOEnZb">To: Arne Limburg <<a href="mailto:arne.limburg@openknowledge.de">arne.limburg@openknowledge.de</a>><br>
Cc: "<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Sent: Wednesday, 10 July 2013, 14:01<br>
Subject: Re: [cdi-dev] CDI and generics<br>
<br>
</div><div class="HOEnZb"><div class="h5">No, it's not necessary. We'll fix this within CDITCK-349 [1]. Leave a<br>
comment if you wish :-)<br>
<br>
Thanks<br>
Martin<br>
<br>
[1]<br>
<a href="https://issues.jboss.org/browse/CDITCK-349" target="_blank">https://issues.jboss.org/browse/CDITCK-349</a><br>
<br>
<br>
Dne 10.7.2013 13:52, Arne Limburg napsal(a):<br>
> OK, so shall I create a TCK issue for that?<br>
><br>
><br>
> Cheers,<br>
> Arne<br>
><br>
> Am 10.07.13 13:50 schrieb "Martin Kouba" unter <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>>:<br>
><br>
>> Hi Arne,<br>
>><br>
>> I think so (except the required type is Baz<List<Qux>>) - there is no<br>
>> bean with assignable bean type for this IP (according to CDI 1.1 rules<br>
>> of course).<br>
>><br>
>> Martin<br>
>><br>
>> Dne 10.7.2013 13:16, Arne Limburg napsal(a):<br>
>>> Hi Martin,<br>
>>><br>
>>> So, which bean should be injected into<br>
>>> @Inject<br>
>>> private Baz<List<T2>> t2BazList;<br>
>>> ?<br>
>>><br>
>>> Baz<T> is also not assignable to Baz<List<String>>, because List<String><br>
>>> is also not assignable from Object.<br>
>>><br>
>>><br>
>>> Am I right, that the test should throw an<br>
>>> UnsatisfiedResolutionException?<br>
>>><br>
>>> Cheers,<br>
>>> Arne<br>
>>><br>
>>> Am 08.07.13 12:17 schrieb "Martin Kouba" unter <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>>:<br>
>>><br>
>>>> Re Arne's question:<br>
>>>> Yes, Baz is a managed bean and AmbiguousResolutionException should not<br>
>>>> be thrown because Qux is not a managed bean (doesn't have a public<br>
>>>> no-arg constructor).<br>
>>>><br>
>>>> Re Marko's findings:<br>
>>>> Yes, the TCK assertions are not up to date and Baz<T> is not assignable<br>
>>>> to Baz<String>, because String is not assignable from Object (no bound<br>
>>>> is defined -> Object is assumed; see JSL 4.4). So I confirm a TCK<br>
>>>> issue.<br>
>>>><br>
>>>> IMO this would deserve a proper cleanup...<br>
>>>><br>
>>>> Martin<br>
>>>><br>
>>>> Dne 8.7.2013 01:22, Marko Lukša napsal(a):<br>
>>>>> I'd say it's a bug. While Baz indeed is a managed bean, it shouldn't<br>
>>>>> be<br>
>>>>> injected into injection point with type Baz<String> nor<br>
>>>>> Baz<List<Qux>>.<br>
>>>>> So I believe you're right in saying that this test should fail with<br>
>>>>> UnsatisfiedResolutionException.<br>
>>>>><br>
>>>>> There was a change made to the spec way back in 2010 (see [1]), but<br>
>>>>> the<br>
>>>>> TCK apparently wasn't updated then. I've filed an issue in the TCK<br>
>>>>> jira<br>
>>>>> [2].<br>
>>>>><br>
>>>>> The problem isn't only in the TCK, but also in the spec itself. Some<br>
>>>>> of<br>
>>>>> the examples in section 5.2.4 don't conform to the rules defined in<br>
>>>>> the<br>
>>>>> same section (according to the rules, bean Dao<T extends Persistent><br>
>>>>> shouldn't be eligible for injection into Dao<Order> or Dao<User>). I<br>
>>>>> remember asking about this a year ago ([3]), but I didn't articulate<br>
>>>>> the<br>
>>>>> problem properly.<br>
>>>>><br>
>>>>> [1]<br>
>>>>><br>
>>>>><br>
>>>>> <a href="https://github.com/cdi-spec/cdi/commit/b32243350ace6a0bba337f91a35f5fd0" target="_blank">https://github.com/cdi-spec/cdi/commit/b32243350ace6a0bba337f91a35f5fd0</a><br>
>>>>> 5c<br>
>>>>> 151f14<br>
>>>>> [2] <a href="https://issues.jboss.org/browse/CDITCK-349" target="_blank">https://issues.jboss.org/browse/CDITCK-349</a><br>
>>>>> [3] <a href="http://lists.jboss.org/pipermail/cdi-dev/2012-April/001742.html" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/2012-April/001742.html</a><br>
>>>>><br>
>>>>> Marko<br>
>>>>><br>
>>>>> On 7.7.2013 16:04, Arne Limburg wrote:<br>
>>>>>> Hi all,<br>
>>>>>><br>
>>>>>> At the OpenWebBeans list we are currently discussing handling of<br>
>>>>>> generics in CDI.<br>
>>>>>> I found a test in the CDI 1.1 TCK, which imho has a bug. The test<br>
>>>>>> is<br>
>>>>>><br>
>>>>>> org.jboss.cdi.tck.tests.inheritance.generics.MemberLevelInheritanceTes<br>
>>>>>> t<br>
>>>>>> and the (simplified) deployment scenario is the following:<br>
>>>>>><br>
>>>>>> public class Baz<T> {<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> public class Qux extends Baz<String> {<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> @Vetoed<br>
>>>>>> public class Bar<T1, T2> {<br>
>>>>>> @Inject<br>
>>>>>> private Baz<T1> baz;<br>
>>>>>> @Inject<br>
>>>>>> private Baz<List<T2>> t2BazList;<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> @RequestScoped<br>
>>>>>> public class Foo extends Bar<String, Qux> {<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> public class Producer {<br>
>>>>>> @Produces<br>
>>>>>> @Amazing<br>
>>>>>> public String produceString() {<br>
>>>>>> return "ok";<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> @Produces<br>
>>>>>> public String[] produceStringArray() {<br>
>>>>>> return new String[0];<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> @Produces<br>
>>>>>> public Baz<Baz<Qux>> produceBazBazQux() {<br>
>>>>>> return new Baz();<br>
>>>>>> }<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> The class Bar has some more injection points, but that does not<br>
>>>>>> matter.<br>
>>>>>> Due to the TCK this deployment should work, but I don't know how.<br>
>>>>>> Question: Is Baz a Bean (I suppose so) and may it be injected into<br>
>>>>>> Bean Foo, more precisely into the second injection point of class<br>
>>>>>> Bar?<br>
>>>>>> - If yes, it also should be injected into the first injection<br>
>>>>>> point, right? This would lead to an AmbiguousResolutionException<br>
>>>>>> since<br>
>>>>>> Qux may also be injected into the first injection point.<br>
>>>>>> - If no, the deployment should fail with a<br>
>>>>>> UnsatisfiedResolutionException since there is no Bean that can be<br>
>>>>>> injected into that injection point.<br>
>>>>>><br>
>>>>>> Is this a bug in the TCK and if not, how is this supposed to work?<br>
>>>>>><br>
>>>>>> Cheers,<br>
>>>>>> Arne<br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> cdi-dev mailing list<br>
>>>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> cdi-dev mailing list<br>
>>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> cdi-dev mailing list<br>
>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>><br>
><br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a></div></div></blockquote></div><br>