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="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>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 class="HOEnZb"><font color="#888888"><br>
<br>
Marko</font></span><div><div class="h5"><br>
<br>
On 16.7.2013 7:17, Romain Manni-Bucau wrote:<br>
</div></div></div><div><div class="h5">
<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>