[JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-437:
-----------------------------------
Agree. The problem is the sorting to pass the info around in AfterTypeDiscovery#getAlternatives().
In this step we loose all the info about the absolute priority values.
> 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 was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 10 months
@Alternative Stereotypes and AfterTypeDiscovery
by Mark Struberg
Hi folks!
There are 3 kind of Alternatives
1.) @Alternative classes activated via beans.xml
2.) @Alternative stereotypes activated via beans.xml
3.) @Alternative classes automatically activated by having a @Priority annotation as well
Question A.):
There is nothing in the spec regarrding @Alternative Stereotypes with @Priority atm. So I assume @Priority on a @Stereotype annotation does exactly nothing, right?
Queation B.):
What if a class has a@Priority annotation and an @Alternative Stereotype? Should those automatically get picked up as Alternative as well?
Quesion C.):
What does AfterTypeDisovery#getAlternatives() really return?
Only the Alternative Classes added via beans.xml or with @Priority? Or all Classes, means also the ones which have an @Alternative @Stereotype?
The later would make more sense to me imo. But is it meant that way? How does Weld behave?
LieGrue,
strub
10 years, 10 months
[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
by Martin Kouba (JIRA)
Martin Kouba created CDI-438:
--------------------------------
Summary: Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
Key: CDI-438
URL: https://issues.jboss.org/browse/CDI-438
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.2.Final
Reporter: Martin Kouba
Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event...
The text:
{quote}
For a producer method with method return type X of a bean with bean class T, the container must raise an event of type ProcessProducerMethod<T, X>.
{quote}
API:
{code:java}
/**
* @param <T> The return type of the producer method
* @param <X> The class of the bean declaring the producer method
*/
public interface ProcessProducerMethod<T, X> extends ProcessBean<X> {
}
{code}
The same applies to {{ProcessProducerField}}.
TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}}.
It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 10 months
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
10 years, 10 months
