[JBoss JIRA] (CDI-394) Section 5.2.4 does not consider multiple bounds
by Marko Lukša (JIRA)
Marko Lukša created CDI-394:
-------------------------------
Summary: Section 5.2.4 does not consider multiple bounds
Key: CDI-394
URL: https://issues.jboss.org/browse/CDI-394
Project: CDI Specification Issues
Issue Type: Bug
Components: Resolution
Affects Versions: 1.1.PFD
Reporter: Marko Lukša
The bullets of section 5.2.4 only talk about a single upper/lower bound, but type variables and wildcards can have many upper bounds.
Incorporating multiple bounds into the rules is not as simple as adding "is assignable from/to *any* upper bound". In some cases, *every* upper bound needs to be assignable from/to a type.
Also, since you can theoretically have {{Foo<T extends Animal & Dog>}} ({{Dog}} of course extends {{Animal}}), simply adding the words *any* or *every* is not enough. Consider the following example:
{code}
Terrier extends Dog extends Animal
required: Foo<M extends Angry & Dog>
bean: Foo<T extends Angry & Dog> assignable
bean: Foo<T extends Angry & Animal> assignable
bean: Foo<T extends Angry & Terrier> not assignable
{code}
In order to take multiple bounds into account, bullet 5 would need to be changed from:
{quote}
• the required type parameter and the bean type parameter are both type variables and *the* upper bound of the required type parameter is assignable to *the* upper bound, if any, of the bean type parameter.
{quote}
to:
{quote}
• the required type parameter and the bean type parameter are both type variables and *each* upper bound of the required type parameter is assignable to *at least one* upper bound of the bean type parameter
{quote}
But, this would incorrectly make the bean type assignable to the required type in the following theoretical cases:
{code}
required: Foo<M extends Angry & Dog>
bean: Foo<T extends Angry & Dog & Terrier> not assignable
bean: Foo<T extends Angry & Animal & Terrier> not assignable
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
Re: [cdi-dev] CDI and generics
by Marko Lukša
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>.
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.).
So this means the change at [1] was a mistake.
[1]
https://github.com/cdi-spec/cdi/commit/b32243350ace6a0bba337f91a35f5fd05c...
Marko
On 16.7.2013 7:17, Romain Manni-Bucau wrote:
>
> 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.
>
> Why CDI wouldnt be able of it out of the box?
>
> 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.
>
> Le 16 juil. 2013 00:15, "Marko Lukša" <marko.luksa(a)gmail.com
> <mailto:marko.luksa@gmail.com>> a écrit :
>
> Actually, it will never be the same instance, since all beans with
> a parameterized bean class must be @Dependent scoped.
>
> Marko
>
> On 15.7.2013 23:46, Arne Limburg wrote:
>> No, I understood you right ;-)
>> In Java the same instance cannot be MyClass<String> and
>> MyClass<Integer> at the same time.
>> We would do exactly that, if we had two injection points like
>> @Inject
>> MyClass<String> myStringClass;
>> @Inject
>> MyClass<Integer> myIntegerClass;
>> 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.
>>
>> Cheers,
>> Arne
>>
>> Von: Romain Manni-Bucau <rmannibucau(a)gmail.com
>> <mailto:rmannibucau@gmail.com>>
>> Datum: Montag, 15. Juli 2013 23:41
>> An: Arne Limburg <arne.limburg(a)openknowledge.de
>> <mailto:arne.limburg@openknowledge.de>>
>> Cc: Mark Struberg <struberg(a)yahoo.de <mailto:struberg@yahoo.de>>,
>> Martin Kouba <mkouba(a)redhat.com <mailto:mkouba@redhat.com>>,
>> "cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>"
>> <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>> Betreff: Re: [cdi-dev] CDI and generics
>>
>> hmm think you misunderstood what i said (sorry if it was unclear)
>>
>> 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>().
>>
>> /Romain Manni-Bucau/
>> /Twitter: @rmannibucau <https://twitter.com/rmannibucau>/
>> /Blog: //http://rmannibucau.wordpress.com//
>> /LinkedIn: //_http://fr.linkedin.com/in/rmannibucau_/
>> /Github: https://github.com/rmannibucau/
>>
>>
>>
>> 2013/7/15 Arne Limburg <arne.limburg(a)openknowledge.de
>> <mailto:arne.limburg@openknowledge.de>>
>>
>> Hi Romain,
>>
>> In plain old java the behavior would depend on where the type
>> variable is declared.
>> See the following samples:
>>
>> public class MyClass<T> {
>>
>> List<T> myList = new ArrayList<T>();
>>
>> List<String> myStringList = myList;
>> }
>>
>> public class MyClass {
>>
>> <T> List<T> myList() {
>> return new ArrayList<T>();
>> }
>>
>> List<String> myStringList = myList();
>> }
>>
>> The first example does not work and the second works.
>>
>> And even, if you would access myList from outside, the first
>> example just works, if you instantiate myClass with the type
>> argument:
>>
>> List<String> myStringList = new MyClass<String>().myList;
>>
>> 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
>> @Inject
>> MyClass<String> myStringClass;
>> @Inject
>> MyClass<Integer> myIntegerClass;
>> 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.
>>
>> 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.
>>
>> I suggest to change the fourth bullet point of chapter 5.2.4:
>> "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,"
>> and add another bullet point:
>> "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"
>> And add a footnote: "If no explicit upper bound is defined,
>> the implicit upper bound java.lang.Object is assumed"
>>
>> BTW. Should we create a spec issue for that?
>>
>> WDYT?
>> Regards,
>> Arne
>>
>> 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)
>>
>> Von: Romain Manni-Bucau <rmannibucau(a)gmail.com
>> <mailto:rmannibucau@gmail.com>>
>> Datum: Montag, 15. Juli 2013 07:55
>> An: Mark Struberg <struberg(a)yahoo.de <mailto:struberg@yahoo.de>>
>> Cc: Martin Kouba <mkouba(a)redhat.com
>> <mailto:mkouba@redhat.com>>, Arne Limburg
>> <arne.limburg(a)openknowledge.de
>> <mailto:arne.limburg@openknowledge.de>>,
>> "cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>"
>> <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>> Betreff: Re: [cdi-dev] CDI and generics
>>
>> +1, if we are no more aligned on something so simple in plain
>> java we are useless i fear :(
>>
>> (i used and saw it used in a lot of real apps)
>>
>>
>> /Romain Manni-Bucau/
>> /Twitter: @rmannibucau <https://twitter.com/rmannibucau>/
>> /Blog: //http://rmannibucau.wordpress.com//
>> /LinkedIn: //_http://fr.linkedin.com/in/rmannibucau_/
>> /Github: https://github.com/rmannibucau/
>>
>>
>>
>> 2013/7/14 Mark Struberg <struberg(a)yahoo.de
>> <mailto:struberg@yahoo.de>>
>>
>> folks, this breaks backward compatibility
>>
>>
>> In CDI 1.0 it was perfectly fine to do the following
>>
>> @Produces
>> @Dependent
>> public <KEY, VALUE extends Serializable> Cache<KEY,
>> VALUE> getDefaultCache(InjectionPoint injectionPoint) {
>> Type ipType = injectionPoint.getType();
>> String cacheName = null;
>>
>> if (ipType instanceof ParameterizedType) {
>> ParameterizedType generic =
>> (ParameterizedType) ipType;
>> Type[] paramTypes =
>> generic.getActualTypeArguments();
>> if (paramTypes == null || paramTypes.length
>> != 2) {
>> throw new RuntimeException("illegal param
>> types for generic type " + ipType);
>> }
>>
>> if (paramTypes[1] instanceof Class) {
>> cacheName = ((Class)
>> paramTypes[1]).getSimpleName();
>> }
>> else {
>> cacheName = paramTypes[1].toString();
>> }
>> }
>>
>> return getCache(cacheName);
>> }
>>
>>
>>
>> usage:
>>
>>
>> @Inject
>> private Cache<String, IdmUser> userCache;
>>
>>
>> With your new interpretation you basically trash this, right?
>> 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...
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: Martin Kouba <mkouba(a)redhat.com
>> <mailto:mkouba@redhat.com>>
>> To: Arne Limburg <arne.limburg(a)openknowledge.de
>> <mailto:arne.limburg@openknowledge.de>>
>> Cc: "cdi-dev(a)lists.jboss.org
>> <mailto:cdi-dev@lists.jboss.org>"
>> <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>> Sent: Wednesday, 10 July 2013, 14:01
>> Subject: Re: [cdi-dev] CDI and generics
>>
>> No, it's not necessary. We'll fix this within CDITCK-349
>> [1]. Leave a
>> comment if you wish :-)
>>
>> Thanks
>> Martin
>>
>> [1]
>> https://issues.jboss.org/browse/CDITCK-349
>>
>>
>> Dne 10.7.2013 13:52, Arne Limburg napsal(a):
>> > OK, so shall I create a TCK issue for that?
>> >
>> >
>> > Cheers,
>> > Arne
>> >
>> > Am 10.07.13 13:50 schrieb "Martin Kouba" unter
>> <mkouba(a)redhat.com <mailto:mkouba@redhat.com>>:
>> >
>> >> 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 <mailto:mkouba@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/b32243350ace6a0bba337f91a35f5fd0
>> >>>>> 5c
>> >>>>> 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.MemberLevelInheritanceTes
>> >>>>>> t
>> >>>>>> 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
>> <mailto:cdi-dev@lists.jboss.org>
>> >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> cdi-dev mailing list
>> >>>>> cdi-dev(a)lists.jboss.org
>> <mailto:cdi-dev@lists.jboss.org>
>> >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>>>>
>> >>>> _______________________________________________
>> >>>> cdi-dev mailing list
>> >>>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >>>
>> >
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
11 years, 5 months
[JBoss JIRA] (CDI-393) Type parameters should not be tested for assignability independently
by Marko Lukša (JIRA)
Marko Lukša created CDI-393:
-------------------------------
Summary: Type parameters should not be tested for assignability independently
Key: CDI-393
URL: https://issues.jboss.org/browse/CDI-393
Project: CDI Specification Issues
Issue Type: Bug
Components: Resolution
Affects Versions: 1.1.PFD
Reporter: Marko Lukša
Sadly, I've found yet another problem with section 5.2.4:
{code}
@Vetoed
class Pair<U, V> {
}
class SymmetricalPairProducer {
@Produces
public <T> Pair<T, T> produceSymmetricalPair(InjectionPoint ip) {
return new Pair<T, T>();
}
}
class Client {
@Inject Pair<String, Integer> asymmetricalPair;
}
{code}
Even though the producer is only able to produce symmetrical pairs, CDI rules allow the symmetrical pair to be injected into the {{asymmetricalPair}} injection point:
- the required type is {{Pair<String, Integer>}}
- the bean type is {{Pair<T, T>}}
- both types are parameterized and have identical raw type and all parameters satisfy the rules:
-- the first required type parameter is an actual type ({{String}}), the first bean type parameter is a type variable ({{T}}) and the actual type is assignable to the upper bound of the type variable
-- the second required type parameter is also an actual type ({{Integer}}), the second bean type parameter is a type variable ({{T}}) and the actual type is assignable to the upper bound of the type variable.
It is clear that type parameters, when they contain type variables, should not be tested for assignability independently.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called
by Matus Abaffy (JIRA)
Matus Abaffy created CDI-392:
--------------------------------
Summary: Clarify when the operations of BeanManager can be called
Key: CDI-392
URL: https://issues.jboss.org/browse/CDI-392
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Matus Abaffy
The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (CDI-391) Type variable always has an upper bound
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-391:
-----------------------------------
Summary: Type variable always has an upper bound
Key: CDI-391
URL: https://issues.jboss.org/browse/CDI-391
Project: CDI Specification Issues
Issue Type: Bug
Components: Resolution
Affects Versions: 1.1.FD
Reporter: Jozef Hartinger
The specification says:
{quote}
the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable from
the upper bound, if any, of the type variable, or
{quote}
or
{quote}
the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable to
the upper bound, if any, of the type variable, or
{quote}
depending on the version of the specification. These *if any* constructs are redundant since JLS defines that every type variable has an upper bound. Even if one is not explicitly declared, java.lang.Object is assumed as the upper bound. This fits the CDI rules well.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.4
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (CDI-390) Clarify that both Order and User extend Persistent in example in section 5.2.4
by Marko Lukša (JIRA)
Marko Lukša created CDI-390:
-------------------------------
Summary: Clarify that both Order and User extend Persistent in example in section 5.2.4
Key: CDI-390
URL: https://issues.jboss.org/browse/CDI-390
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.1.PFD
Reporter: Marko Lukša
Priority: Minor
The example doesn't specify that either Order or User extend Persistent. This must be assumed by the reader.
Also, one other thing: when a reader is reading the spec, they come across the following sentence: "For example, Dao is eligible for injection to any injection point of type..." and it's not immediately clear what Dao it is talking about, since Dao is defined later (currently not even on the same page in the PDF). It would be much clearer if the Dao was defined earlier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (CDI-389) Revert CDI-85
by Marko Lukša (JIRA)
Marko Lukša created CDI-389:
-------------------------------
Summary: Revert CDI-85
Key: CDI-389
URL: https://issues.jboss.org/browse/CDI-389
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.1.PFD
Reporter: Marko Lukša
Bullet 4 of section 5.2.4 should be reverted back from:
{quote}
the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
the upper bound, if any, of the type variable, or
{quote}
to
{quote}
the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
the upper bound, if any, of the type variable, or
{quote}
See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (CDI-386) Two examples in section 5.2.4 contradict the rules of the same section
by Marko Lukša (JIRA)
[ https://issues.jboss.org/browse/CDI-386?page=com.atlassian.jira.plugin.sy... ]
Marko Lukša resolved CDI-386.
-----------------------------
Assignee: Marko Lukša
Resolution: Rejected
CDI-85 will be reverted, which will make the examples correct again.
> Two examples in section 5.2.4 contradict the rules of the same section
> ----------------------------------------------------------------------
>
> Key: CDI-386
> URL: https://issues.jboss.org/browse/CDI-386
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
> Assignee: Marko Lukša
>
> The examples in section 5.2.4 state that bean {{Dao<T extends Persistent>}} is eligible for injection into both {{Dao<Order>}} and {{Dao<User>}}, but according to the rules stated in the same section this isn't true.
> Also note that the spec doesn't state explicitly that {{Order extends Persistent}} and {{User extends Persistent}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (CDI-387) Incorrect rule regarding assignability of parameterized types when both bean type parameter and required type parameter are type variables
by Marko Lukša (JIRA)
[ https://issues.jboss.org/browse/CDI-387?page=com.atlassian.jira.plugin.sy... ]
Marko Lukša resolved CDI-387.
-----------------------------
Assignee: Marko Lukša
Resolution: Rejected
Actually, the rule is correct, because CDI-85 was a mistake and should be reverted.
> Incorrect rule regarding assignability of parameterized types when both bean type parameter and required type parameter are type variables
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-387
> URL: https://issues.jboss.org/browse/CDI-387
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD, 1.1.FD
> Reporter: Marko Lukša
> Assignee: Marko Lukša
>
> Say we have the following required type:
> {code}
> Dao<X extends Medium>
> {code}
> and classes:
> {code}
> class Small {...}
> class Medium extends Small {...}
> class Big extends Medium {...}
> {code}
> According to the last bullet of section 5.2.4.,
> bean type {{Dao<X extends Small>}} is assignable to the required type {{Dao<X extends Medium>}}, since the required type parameter and bean type parameter are both type variables and the upper bound of the required type parameter ({{Medium}}) is assignable to the upper bound of the bean type parameter ({{Small}}).
> On the other hand, according to the same rules, bean type {{Dao<X extends Big>}} is not assignable to required type {{Dao<X extends Medium>}}.
> It should be the other way around.
> Bullet 5 should be corrected in the same way bullet 4 was corrected in CDI-85. The upper bound of the required type parameter should be assignable *from* the upper bound of the bean type parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (CDI-387) Incorrect rule regarding assignability of parameterized types when both bean type parameter and required type parameter are type variables
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-387?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger updated CDI-387:
--------------------------------
Affects Version/s: 1.1.FD
> Incorrect rule regarding assignability of parameterized types when both bean type parameter and required type parameter are type variables
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-387
> URL: https://issues.jboss.org/browse/CDI-387
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD, 1.1.FD
> Reporter: Marko Lukša
>
> Say we have the following required type:
> {code}
> Dao<X extends Medium>
> {code}
> and classes:
> {code}
> class Small {...}
> class Medium extends Small {...}
> class Big extends Medium {...}
> {code}
> According to the last bullet of section 5.2.4.,
> bean type {{Dao<X extends Small>}} is assignable to the required type {{Dao<X extends Medium>}}, since the required type parameter and bean type parameter are both type variables and the upper bound of the required type parameter ({{Medium}}) is assignable to the upper bound of the bean type parameter ({{Small}}).
> On the other hand, according to the same rules, bean type {{Dao<X extends Big>}} is not assignable to required type {{Dao<X extends Medium>}}.
> It should be the other way around.
> Bullet 5 should be corrected in the same way bullet 4 was corrected in CDI-85. The upper bound of the required type parameter should be assignable *from* the upper bound of the bean type parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months