no no, what i say is CDI could handle generic beans as template it would duplicate as many time as needed to match all instances. the same as for @Dependent but with the scope you want. there is no technical blocking point.<div>
<br clear="all"><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/16 Marko Lukša <span dir="ltr"><<a href="mailto:marko.luksa@gmail.com" target="_blank">marko.luksa@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Yes, you'd need an extension that
registers multiple beans. But that's how it needs to be. <br>
<br>
It's not sad. This simply can't work. If you inject the same
instance into both @Inject List<String> stringList and
@Inject List<Integer> integerList, then the user can do
this:<br>
<br>
stringList.add("some string");<br>
integerList.add(15);<br>
for (String str : stringList) {<br>
System.out.println(str);<br>
}<br>
<br>
which would result in a ClassCastException, right?<span class="HOEnZb"><font color="#888888"><br>
<br>
Marko</font></span><div><div class="h5"><br>
<br>
On 16.7.2013 9:23, Romain Manni-Bucau wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">hmm, and if you don't want a @Dependent? it is doable
through an extension but not through declaration, that's sad IMO
<div><br clear="all">
<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>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/16 Marko Lukša <span dir="ltr"><<a href="mailto:marko.luksa@gmail.com" target="_blank">marko.luksa@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>What Arne was concerned about is that we cannot
inject the same instance into two different typed
injection points. We can't have an object that is a list
of strings and a list of integers at the same time. We
would need such an object if we wanted to inject it into
both @Inject List<String> and @Inject
List<Integer>. <br>
<br>
What I pointed out is that CDI has this covered, as it
requires all beans with a parameterized bean class to be
dependent scoped and by definition not sharable across
multiple injection points. CDI will create a _new
instance_ for each injection point, therefore it
actually can inject bean MyClass<T> into both
@Inject MyClass<String> and @Inject
MyClass<Integer>, since it injects two different
instances. There is no need to have a custom extension
and register MyClass<T> multiple times (as
MyClass<String>, MyClass<Integer>, etc.). <br>
<br>
So this means the change at [1] was a mistake. <br>
<br>
[1] <a href="https://github.com/cdi-spec/cdi/commit/b32243350ace6a0bba337f91a35f5fd05c151f14" target="_blank">https://github.com/cdi-spec/cdi/commit/b32243350ace6a0bba337f91a35f5fd05c151f14</a><span><font color="#888888"><br>
<br>
Marko</font></span>
<div>
<div><br>
<br>
On 16.7.2013 7:17, Romain Manni-Bucau wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<p>Hmm not sure i get the Dependent limit. Using a
custom extension you'll register the same bean as
many times as needed but using different values
for parameters and the scope you want.</p>
<p>Why CDI wouldnt be able of it out of the box?</p>
<p>It is really something basic in 2013 and find
really sad that's look so complicated. Please
explain me what i'm missing if so.</p>
<div class="gmail_quote">Le 16 juil. 2013 00:15,
"Marko Lukša" <<a href="mailto:marko.luksa@gmail.com" target="_blank">marko.luksa@gmail.com</a>> a
écrit :<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Actually, it will never be the same
instance, since all beans with a
parameterized bean class must be @Dependent
scoped.<br>
<br>
Marko<br>
<br>
On 15.7.2013 23:46, Arne Limburg wrote:<br>
</div>
<blockquote type="cite">
<div>No, I understood you right ;-)</div>
<div>In Java the same instance cannot be
MyClass<String> and
MyClass<Integer> at the same time.</div>
<div>We would do exactly that, if we had two
injection points like</div>
<div>@Inject</div>
<div>MyClass<String> myStringClass;</div>
<div>@Inject</div>
<div>MyClass<Integer> myIntegerClass;</div>
<div>In plain java this could never be the
same instances without heavy
(compile-time) casting, thus this should
not be the same instances in CDI.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Arne</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">Von:
</span>Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>><br>
<span style="font-weight:bold">Datum: </span>Montag,
15. Juli 2013 23:41<br>
<span style="font-weight:bold">An: </span>Arne
Limburg <<a href="mailto:arne.limburg@openknowledge.de" target="_blank">arne.limburg@openknowledge.de</a>><br>
<span style="font-weight:bold">Cc: </span>Mark
Struberg <<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>>,
Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>,
"<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>"
<<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
<span style="font-weight:bold">Betreff:
</span>Re: [cdi-dev] CDI and generics<br>
</div>
<div><br>
</div>
<div>
<div>hmm think you misunderstood what i
said (sorry if it was unclear)
<div><br>
</div>
<div>basically my point was a generic
bean or produced bean should be
injectable everywhere so
MyClass<T> should match
@Inject MyClass<String>. In
plain java we do: new
MyClass<String>().</div>
<div><br clear="all">
<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>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/15
Arne Limburg <span dir="ltr"><<a href="mailto:arne.limburg@openknowledge.de" target="_blank">arne.limburg@openknowledge.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>Hi Romain,</div>
</div>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">In
plain old java the behavior
would depend on where the
type variable is declared.</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">See
the following samples:</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">public
class MyClass<T> {</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">
List<T> myList = new
ArrayList<T>();</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">
List<String>
myStringList = myList;</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">}</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">public
class MyClass {</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">
<T> List<T>
myList() {</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">
return new
ArrayList<T>();</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">
}</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">
List<String>
myStringList = myList();</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">}</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">The
first example does not work
and the second works.</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">And
even, if you would access
myList from outside, the
first example just works, if
you instantiate myClass with
the type argument:</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">List<String>
myStringList = new
MyClass<String>().myList;</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">To
transfer this to CDI: We
would need an instance of
Bean MyClass with
MyClass<String> in the
type closure. And we would
have to do this for every
type argument that can be
found within the injection
points, i.e., if we had the
injection points</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">@Inject</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">MyClass<String>
myStringClass;</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">@Inject</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">MyClass<Integer>
myIntegerClass;</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">either
the type closure of my class
would have to contain
MyClass<String> AND
MyClass<Integer> or we
would need to have different
beans for both types. I
think, we cannot do either.</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">I
suggest to handle
TypeVariables declared at
class level different than
TypeVariables declared at
(producer-)method level.
Thus we could handle Mark
Strubergs case and leave the
rest like it is in plain old
java.</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div><font style="font-size:14px" face="Calibri,sans-serif">I
suggest to change the
fourth bullet po</font>int
of chapter 5.2.4:</div>
<div>"the required type
parameter is an actual type,
the bean type parameter is a
type variable that is
declared at class level and
the actual type is
assignable from the upper
bound of the type variable,"</div>
<div>and add another bullet
point:</div>
<div>"the required type
parameter is an actual type,
the bean type parameter is a
type variable that is
declared at method level and
the actual type is
assignable to the upper
bound of the type variable,
or"</div>
<div>And add a footnote: "If
no explicit upper bound is
defined, the implicit upper
bound java.lang.Object is
assumed"</div>
<div><br>
</div>
<div>BTW. Should we create a
spec issue for that?</div>
<div><br>
</div>
<div>WDYT?</div>
<div>Regards,</div>
<div>Arne</div>
<div><br>
</div>
<div>P.S.: I don't think this
is a backward compatibility
issue, just because Weld and
OpenWebBeans implemented it
differently in the past. It
just was not clear in 1.0
and is not in 1.1. The
misleading part is the "if
any" in the fourth bullet
point. A TypeVariable ALWAYS
has an upper bound. "If no
bound is given for a type
variable, Object is assumed"
(Java Lang Spec 4.4)</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<span style="font-size:14px;font-family:Calibri,sans-serif">
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">Von:
</span>Romain Manni-Bucau
<<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>><br>
<span style="font-weight:bold">Datum:
</span>Montag, 15. Juli
2013 07:55<br>
<span style="font-weight:bold">An:
</span>Mark Struberg <<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>><br>
<span style="font-weight:bold">Cc:
</span>Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>,
Arne Limburg <<a href="mailto:arne.limburg@openknowledge.de" target="_blank">arne.limburg@openknowledge.de</a>>,
"<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>"
<<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
<span style="font-weight:bold">Betreff:
</span>Re: [cdi-dev] CDI
and generics<br>
</div>
<div>
<div>
<div><br>
</div>
<div>
<div>
<p style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">+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-size:13px;font-family:arial,sans-serif">(i
used and saw it
used in a lot of
real apps)</p>
<p style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><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>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><br>
<br>
<br>
LieGrue,<br>
strub<br>
<br>
<br>
<br>
<br>
<br>
----- Original
Message -----<br>
From: Martin
Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>><br>
</div>
<div>To: Arne
Limburg <<a href="mailto:arne.limburg@openknowledge.de" target="_blank">arne.limburg@openknowledge.de</a>><br>
Cc: "<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>"
<<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">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>
<div>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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div>
</div>
</div>
</div>
</span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span> <br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
cdi-dev mailing list
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a></pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">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>
</blockquote>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>