Events and Type Variables in CDI 1.1
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
9 years, 12 months
[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
[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
[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
[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
[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