April 2014 - cdi-dev - Jboss List Archives

by Arne Limburg

Hi, I found an issue in either the spec or the tck, which I would like to discuss: The TCK-Test org.jboss.cdi.tck.tests.event.fires.FireEventTest.testTypeVariableEventTypeFails uses the following bean to fire an event by calling the method fireWithTypeVariable() public class Bar { @Inject private Event<Foo<? extends Number>> event; public <T extends Number> void fireWithTypeVariable() { event.fire(new Foo<T>()); } } The TCK expects this test to fail because of the type variable in the instance created by new Foo<T>() However, the spec states in 10.3.1 „If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.“ Imho in this case the container is able to resolve T to "? extends Number“ and the spec does not prohibit an event to have a wildcard type. So since T is not unresolvable, this test case should not expect the container to throw an exception. If we consider T not to be resolved, because it resolves to a wildcard type, we should mention this somewhere in the spec. Or am I missing something? Cheers, Arne

10 years, 5 months

3
5
0 / 0

[JBoss JIRA] (CDI-436) Specialization requirements do not allow parameterized types to be specialized

by Matus Abaffy (JIRA)

[ https://issues.jboss.org/browse/CDI-436?page=com.atlassian.jira.plugin.sy... ] Matus Abaffy commented on CDI-436: ---------------------------------- Actually, if X<...> specializes Y<...>, then bean X cannot have some "more general" bean type than bean Y (otherwise it could not extend it, or override it in the case of producer methods). So if X has a bean type U that is assignable from (more general than) bean type T of Y, then U and T must really be the same. Just not necessarily equal in the java sense. > Specialization requirements do not allow parameterized types to be specialized > ------------------------------------------------------------------------------ > > Key: CDI-436 > URL: https://issues.jboss.org/browse/CDI-436 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Matus Abaffy > > {quote} > Formally, a bean X is said to specialize another bean Y if either: > ... > Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error. > {quote} > The tricky part about having all the bean types is that two parameterized types might not equal (in the java sense) even though they "are the same". That's because of the inequality between type variables. Example: > {code} > class Foo<T> {} > {code} > {code} > class Bar<T> extends Foo<T> {} > {code} > Bar seems to have all the bean types of Foo, but it does not. Foo<T> from class Bar is not equal to Foo<T> from class Foo. > I suppose the intention of the spec. was that if bean X specializes bean Y, then for each bean type T of Y, X must have a bean type U that is assignable from T. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-434: ---------------------------------- I've created a separate issue for the problem mentioned in the last comment - see CDI-437. > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDi... > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly

by Martin Kouba (JIRA)

Martin Kouba created CDI-437: -------------------------------- Summary: The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly Key: CDI-437 URL: https://issues.jboss.org/browse/CDI-437 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Martin Kouba {quote} Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. {quote} However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. The container can either: * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering The first option seems to be less harmful. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-436) Specialization requirements do not allow parameterized types to be specialized

by Matus Abaffy (JIRA)

[ https://issues.jboss.org/browse/CDI-436?page=com.atlassian.jira.plugin.sy... ] Matus Abaffy updated CDI-436: ----------------------------- Affects Version/s: 1.2.Final > Specialization requirements do not allow parameterized types to be specialized > ------------------------------------------------------------------------------ > > Key: CDI-436 > URL: https://issues.jboss.org/browse/CDI-436 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Matus Abaffy > > {quote} > Formally, a bean X is said to specialize another bean Y if either: > ... > Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error. > {quote} > The tricky part about having all the bean types is that two parameterized types might not equal (in the java sense) even though they "are the same". That's because of the inequality between type variables. Example: > {code} > class Foo<T> {} > {code} > {code} > class Bar<T> extends Foo<T> {} > {code} > Bar seems to have all the bean types of Foo, but it does not. Foo<T> from class Bar is not equal to Foo<T> from class Foo. > I suppose the intention of the spec. was that if bean X specializes bean Y, then for each bean type T of Y, X must have a bean type U that is assignable from T. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-436) Specialization requirements do not allow parameterized types to be specialized

by Matus Abaffy (JIRA)

Matus Abaffy created CDI-436: -------------------------------- Summary: Specialization requirements do not allow parameterized types to be specialized Key: CDI-436 URL: https://issues.jboss.org/browse/CDI-436 Project: CDI Specification Issues Issue Type: Bug Reporter: Matus Abaffy {quote} Formally, a bean X is said to specialize another bean Y if either: ... Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error. {quote} The tricky part about having all the bean types is that two parameterized types might not equal (in the java sense) even though they "are the same". That's because of the inequality between type variables. Example: {code} class Foo<T> {} {code} {code} class Bar<T> extends Foo<T> {} {code} Bar seems to have all the bean types of Foo, but it does not. Foo<T> from class Bar is not equal to Foo<T> from class Foo. I suppose the intention of the spec. was that if bean X specializes bean Y, then for each bean type T of Y, X must have a bean type U that is assignable from T. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-434: ---------------------------------- Note that for alternatives the following paragraph is misleading: {quote} Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. The container must use the final values of these collections, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. {quote} The problem is that the priority value of an alternative is used during resolution and thus the ordering of the alternatives collection does not matter. The container may use the final values to identify removed/deselected alternatives and to declare a new selected alternative for an application - without priority value. However, it must preserve the original priorities to perform resolution correctly. > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDi... > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-434: ---------------------------------- The spec is also not clear whether "the ordered list" means ascending or descending order. I believe the intent was to have it sorted by priority in ascending order. > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDi... > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.sy... ] Martin Kouba reassigned CDI-434: -------------------------------- Assignee: Martin Kouba > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDi... > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-435) cdi-spec.org/faq outdated

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-435: ----------------------------------- Summary: cdi-spec.org/faq outdated Key: CDI-435 URL: https://issues.jboss.org/browse/CDI-435 Project: CDI Specification Issues Issue Type: Bug Reporter: Jozef Hartinger Assignee: Antoine Sabot-Durand Frequently asked questions at http://www.cdi-spec.org/faq/ are outdated - mostly in sync with CDI 1.0 or CDI 1.1. -- 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

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2014