From jharting at redhat.com  Fri May  2 10:20:43 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 02 May 2014 16:20:43 +0200
Subject: [cdi-dev] Events and Type Variables in CDI 1.1
In-Reply-To: <CF8700DC.41E11%arne.limburg@openknowledge.de>
References: <CF8700DC.41E11%arne.limburg@openknowledge.de>
Message-ID: <5363A9BB.4090100@redhat.com>

Hi,

I think this is a spec issue. The spec should make it clearer that a 
"resolvable type variable" means a type variable that can be resolved to 
a reference type other than a type variable.

Jozef

On 04/30/2014 09:32 PM, Arne Limburg wrote:
> 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()
>
> publicclassBar {
>
>
> @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
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140502/84cf523b/attachment.html 

From arne.limburg at openknowledge.de  Sun May  4 16:24:07 2014
From: arne.limburg at openknowledge.de (Arne Limburg)
Date: Sun, 4 May 2014 20:24:07 +0000
Subject: [cdi-dev] Events and Type Variables in CDI 1.1
In-Reply-To: <5363A9BB.4090100@redhat.com>
Message-ID: <CF8C6C4C.41F41%arne.limburg@openknowledge.de>

Hi Jozef,

In this case the type variable can be resolved to a wildcard type. Should this be legal or not? For now, I find to wording in the spec that forbids the event type to resolve to a wildcard type. So this may be a spec issue AND a tck issue. Shall I create a ticket for it?

Cheers,
Arne

Von: Jozef Hartinger <jharting at redhat.com<mailto:jharting at redhat.com>>
Datum: Freitag, 2. Mai 2014 16:20
An: Arne Limburg <arne.limburg at openknowledge.de<mailto:arne.limburg at openknowledge.de>>
Cc: "cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>" <cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>>
Betreff: Re: [cdi-dev] Events and Type Variables in CDI 1.1

Hi,

I think this is a spec issue. The spec should make it clearer that a "resolvable type variable" means a type variable that can be resolved to a reference type other than a type variable.

Jozef

On 04/30/2014 09:32 PM, Arne Limburg wrote:
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



_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org<mailto:cdi-dev at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/cdi-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140504/1c2c340c/attachment-0001.html 

From jharting at redhat.com  Mon May  5 02:46:39 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 05 May 2014 08:46:39 +0200
Subject: [cdi-dev] Events and Type Variables in CDI 1.1
In-Reply-To: <CF8C6C4C.41F41%arne.limburg@openknowledge.de>
References: <CF8C6C4C.41F41%arne.limburg@openknowledge.de>
Message-ID: <536733CF.3080701@redhat.com>

Yes, go ahead with the spec issue.

Jozef

On 05/04/2014 10:24 PM, Arne Limburg wrote:
> Hi Jozef,
>
> In this case the type variable can be resolved to a wildcard type. 
> Should this be legal or not? For now, I find to wording in the spec 
> that forbids the event type to resolve to a wildcard type. So this may 
> be a spec issue AND a tck issue. Shall I create a ticket for it?
>
> Cheers,
> Arne
>
> Von: Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>>
> Datum: Freitag, 2. Mai 2014 16:20
> An: Arne Limburg <arne.limburg at openknowledge.de 
> <mailto:arne.limburg at openknowledge.de>>
> Cc: "cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>" 
> <cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
> Betreff: Re: [cdi-dev] Events and Type Variables in CDI 1.1
>
> Hi,
>
> I think this is a spec issue. The spec should make it clearer that a 
> "resolvable type variable" means a type variable that can be resolved 
> to a reference type other than a type variable.
>
> Jozef
>
> On 04/30/2014 09:32 PM, Arne Limburg wrote:
>> 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()
>>
>> publicclassBar {
>>
>>
>> @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
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140505/9bc91616/attachment.html 

From mkouba at redhat.com  Mon May  5 03:29:46 2014
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 05 May 2014 09:29:46 +0200
Subject: [cdi-dev] Events and Type Variables in CDI 1.1
In-Reply-To: <536733CF.3080701@redhat.com>
References: <CF8C6C4C.41F41%arne.limburg@openknowledge.de>
	<536733CF.3080701@redhat.com>
Message-ID: <53673DEA.7010803@redhat.com>

Hi,

I may be wrong, but I always thought a wildcard represents an unknown
type and cannot be used for instance creation. So I believe "T" is not
resolvable in this use-case. The spec states in 10.1: "An event object
is an instance of a concrete Java class with no unresolvable type
variables. The event types of the event include all superclasses and
interfaces of the runtime class of the event object.". In other words an
event type may not contain a wildcard. Note that a parameterized type
that contains a wildcard type parameter is not a legal bean type either.
Still the spec should clarify what "resolvable" means and maybe
explicitly forbid wildcards in event types.

Martin

Dne 5.5.2014 08:46, Jozef Hartinger napsal(a):
> Yes, go ahead with the spec issue.
> 
> Jozef
> 
> On 05/04/2014 10:24 PM, Arne Limburg wrote:
>> Hi Jozef,
>>
>> In this case the type variable can be resolved to a wildcard type.
>> Should this be legal or not? For now, I find to wording in the spec
>> that forbids the event type to resolve to a wildcard type. So this may
>> be a spec issue AND a tck issue. Shall I create a ticket for it?
>>
>> Cheers,
>> Arne
>>
>> Von: Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>>
>> Datum: Freitag, 2. Mai 2014 16:20
>> An: Arne Limburg <arne.limburg at openknowledge.de
>> <mailto:arne.limburg at openknowledge.de>>
>> Cc: "cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>"
>> <cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
>> Betreff: Re: [cdi-dev] Events and Type Variables in CDI 1.1
>>
>> Hi,
>>
>> I think this is a spec issue. The spec should make it clearer that a
>> "resolvable type variable" means a type variable that can be resolved
>> to a reference type other than a type variable.
>>
>> Jozef
>>
>> On 04/30/2014 09:32 PM, Arne Limburg wrote:
>>> 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()
>>>
>>> publicclassBar {
>>>
>>>
>>>     @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
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>>
> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 

From arne.limburg at openknowledge.de  Tue May  6 03:31:58 2014
From: arne.limburg at openknowledge.de (Arne Limburg)
Date: Tue, 6 May 2014 07:31:58 +0000
Subject: [cdi-dev] Events and Type Variables in CDI 1.1
In-Reply-To: <53673DEA.7010803@redhat.com>
Message-ID: <CF8E5250.421D8%arne.limburg@openknowledge.de>

Hi Martin,

Your view on that seems reasonable, but the spec does not state so:

An event object is an instance of a concrete Java class with no
unresolvable type "variables"

And a Wildcard is surely not type variable. So I am with Jozef. This is a
spec issue. As you, too, wrote, we should explicitly forbid wildcard types
in event object

I?ll create a spec issue for that.

Cheers,
Arne


Am 05.05.14 09:29 schrieb "Martin Kouba" unter <mkouba at redhat.com>:

>Hi,
>
>I may be wrong, but I always thought a wildcard represents an unknown
>type and cannot be used for instance creation. So I believe "T" is not
>resolvable in this use-case. The spec states in 10.1: "An event object
>is an instance of a concrete Java class with no unresolvable type
>variables. The event types of the event include all superclasses and
>interfaces of the runtime class of the event object.". In other words an
>event type may not contain a wildcard. Note that a parameterized type
>that contains a wildcard type parameter is not a legal bean type either.
>Still the spec should clarify what "resolvable" means and maybe
>explicitly forbid wildcards in event types.
>
>Martin
>
>Dne 5.5.2014 08:46, Jozef Hartinger napsal(a):
>> Yes, go ahead with the spec issue.
>> 
>> Jozef
>> 
>> On 05/04/2014 10:24 PM, Arne Limburg wrote:
>>> Hi Jozef,
>>>
>>> In this case the type variable can be resolved to a wildcard type.
>>> Should this be legal or not? For now, I find to wording in the spec
>>> that forbids the event type to resolve to a wildcard type. So this may
>>> be a spec issue AND a tck issue. Shall I create a ticket for it?
>>>
>>> Cheers,
>>> Arne
>>>
>>> Von: Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>>
>>> Datum: Freitag, 2. Mai 2014 16:20
>>> An: Arne Limburg <arne.limburg at openknowledge.de
>>> <mailto:arne.limburg at openknowledge.de>>
>>> Cc: "cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>"
>>> <cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
>>> Betreff: Re: [cdi-dev] Events and Type Variables in CDI 1.1
>>>
>>> Hi,
>>>
>>> I think this is a spec issue. The spec should make it clearer that a
>>> "resolvable type variable" means a type variable that can be resolved
>>> to a reference type other than a type variable.
>>>
>>> Jozef
>>>
>>> On 04/30/2014 09:32 PM, Arne Limburg wrote:
>>>> 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.testTypeVariableEvent
>>>>TypeFails
>>>> uses the following bean to fire an event by calling the method
>>>> fireWithTypeVariable()
>>>>
>>>> publicclassBar {
>>>>
>>>>
>>>>     @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
>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> 
>>>>cdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 



From issues at jboss.org  Wed May  7 08:52:56 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 7 May 2014 08:52:56 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering in
 ProcessProducerMethod and ProcessProducerField events
In-Reply-To: <JIRA.12540105.1399467093367@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540105.1399467093367@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540105.1399467093367.10821.1399467176740@jira02.app.mwc.hst.phx2.redhat.com>

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)

From struberg at yahoo.de  Mon May 12 02:29:58 2014
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 12 May 2014 07:29:58 +0100 (BST)
Subject: [cdi-dev] @Alternative Stereotypes and AfterTypeDiscovery
Message-ID: <1399876198.84976.YahooMailNeo@web28901.mail.ir2.yahoo.com>

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140512/6f71e541/attachment-0001.html 

From mkouba at redhat.com  Mon May 12 03:52:23 2014
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 12 May 2014 09:52:23 +0200
Subject: [cdi-dev] @Alternative Stereotypes and AfterTypeDiscovery
In-Reply-To: <1399876198.84976.YahooMailNeo@web28901.mail.ir2.yahoo.com>
References: <1399876198.84976.YahooMailNeo@web28901.mail.ir2.yahoo.com>
Message-ID: <53707DB7.5010107@redhat.com>

Hi Mark,

comments inline.

Dne 12.5.2014 08:29, Mark Struberg napsal(a):
> 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?

I think so.

> 
> 
> Queation B.):
> What if a class has a at Priority annotation and an @Alternative
> Stereotype? Should those automatically get picked up as Alternative as well?
> 

I believe it should be selected. "2.7.1. Declaring an alternative"
states it's an alternative and "5.1.1 Declaring selected alternatives"
states it should be selected for an entire application. I'm not sure if
it works in Weld though... In any case it's a good candidate for a TCK
test, I will create a new TCK issue.

> ..
> 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?
> 

AfterTypeDisovery#getAlternatives() should return "the ordered list of
enabled alternatives for the application" -> @Priority only. Note that
the event is fired globally so you can't include all the selected
alternatives.

However, the javadoc is outdated right now (see CDI-434). And I also
found another issue with ATD#getAlternatives() (see CDI-437).

> 
> LieGrue,
> strub
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 


From issues at jboss.org  Tue May 13 06:50:56 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 13 May 2014 06:50:56 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final
 value of AfterTypeDiscovery.getAlternatives() properly
In-Reply-To: <JIRA.12539393.1398845910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12539393.1398845910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539393.1398845910000.19676.1399978256266@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967430#comment-12967430 ] 

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)

From issues at jboss.org  Mon May 19 09:38:57 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 19 May 2014 09:38:57 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event
In-Reply-To: <JIRA.12541124.1400506656349@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541124.1400506656349@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656349.29518.1400506737057@jira02.app.mwc.hst.phx2.redhat.com>

Martin Kouba created CDI-439:
--------------------------------

             Summary: ProcessBean event 
                 Key: CDI-439
                 URL: https://issues.jboss.org/browse/CDI-439
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba






--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon May 19 09:40:57 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 19 May 2014 09:40:57 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.29528.1400506857591@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/CDI-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-439:
-----------------------------

     Summary: ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()  (was: ProcessBean event )
    Priority: Minor  (was: Major)


> ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()
> ----------------------------------------------------------------------------
>
>                 Key: CDI-439
>                 URL: https://issues.jboss.org/browse/CDI-439
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon May 19 09:40:57 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 19 May 2014 09:40:57 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.29529.1400506857695@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/CDI-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-439:
-----------------------------

    Description: Right now, "11.5.10. ProcessBean event" does not state anything about 


> ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()
> ----------------------------------------------------------------------------
>
>                 Key: CDI-439
>                 URL: https://issues.jboss.org/browse/CDI-439
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Minor
>
> Right now, "11.5.10. ProcessBean event" does not state anything about 



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon May 19 09:42:57 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 19 May 2014 09:42:57 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.29532.1400506977043@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/CDI-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-439:
-----------------------------

    Description: Right now, "11.5.10. ProcessBean event" does not state anything about the fact that AfterBeanDiscovery#addBean() fires an event of type +ProcessBean+ (no subtype as the info is not available for custom Bean implementation).  (was: Right now, "11.5.10. ProcessBean event" does not state anything about )


> ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()
> ----------------------------------------------------------------------------
>
>                 Key: CDI-439
>                 URL: https://issues.jboss.org/browse/CDI-439
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Priority: Minor
>
> Right now, "11.5.10. ProcessBean event" does not state anything about the fact that AfterBeanDiscovery#addBean() fires an event of type +ProcessBean+ (no subtype as the info is not available for custom Bean implementation).



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon May 19 09:42:57 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 19 May 2014 09:42:57 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.29533.1400506977104@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/CDI-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-439:
-----------------------------

    Affects Version/s: 1.2.Final


> ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()
> ----------------------------------------------------------------------------
>
>                 Key: CDI-439
>                 URL: https://issues.jboss.org/browse/CDI-439
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Priority: Minor
>
> Right now, "11.5.10. ProcessBean event" does not state anything about the fact that AfterBeanDiscovery#addBean() fires an event of type +ProcessBean+ (no subtype as the info is not available for custom Bean implementation).



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon May 19 09:44:56 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 19 May 2014 09:44:56 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541124.1400506656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.29535.1400507096222@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/CDI-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-439:
-----------------------------

    Description: Right now, "11.5.10. ProcessBean event" does not state anything about the fact that {{AfterBeanDiscovery#addBean()}} fires an event of type {{ProcessBean}} (no subtype as the info is not available for custom Bean implementation).  (was: Right now, "11.5.10. ProcessBean event" does not state anything about the fact that AfterBeanDiscovery#addBean() fires an event of type +ProcessBean+ (no subtype as the info is not available for custom Bean implementation).)


> ProcessBean event section - make a reference to AfterBeanDiscovery#addBean()
> ----------------------------------------------------------------------------
>
>                 Key: CDI-439
>                 URL: https://issues.jboss.org/browse/CDI-439
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Priority: Minor
>
> Right now, "11.5.10. ProcessBean event" does not state anything about the fact that {{AfterBeanDiscovery#addBean()}} fires an event of type {{ProcessBean}} (no subtype as the info is not available for custom Bean implementation).



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon May 26 10:55:59 2014
From: issues at jboss.org (Matus Abaffy (JIRA))
Date: Mon, 26 May 2014 10:55:59 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-440) Clarify assignability rules for
 parameterized types with type variables with multiple bounds
In-Reply-To: <JIRA.12541893.1401116112692@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541893.1401116112692@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541893.1401116112692.42372.1401116159088@jira02.app.mwc.hst.phx2.redhat.com>

Matus Abaffy created CDI-440:
--------------------------------

             Summary: Clarify assignability rules for parameterized types with type variables with multiple bounds
                 Key: CDI-440
                 URL: https://issues.jboss.org/browse/CDI-440
             Project: CDI Specification Issues
          Issue Type: Clarification
    Affects Versions: 1.2.Final
            Reporter: Matus Abaffy


Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds.

For example, the bullet
??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.??
should have meaning similar to:
... for each upper bound T of the bean type parameter, there is a (at least one) type variable of the required type which is assignable to T.

Consider the following example:
\- interfaces Bar, Baz, Foo
{code}
class BarImpl implements Bar { ... }
{code}
{code}
interface MyInterface<T> { ... }
{code}
\- bean:
{code}
class MyBean<T extends Bar & Baz & Foo> implements MyInterface<T> { ... }
{code}
\- injection point:
{code}
class TestClass<U extends BarImpl & Baz> {
@Inject
MyInterface<U> bean;
}
{code}
MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected.

Please, correct me if I am wrong.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From antoine at sabot-durand.net  Wed May 28 06:05:52 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 28 May 2014 12:05:52 +0200
Subject: [cdi-dev] CDI 2.0 survey launched
Message-ID: <FBCEE5F2-E061-4033-9E53-D3320D533F94@sabot-durand.net>

Hi all,

Pete and I just launched a survey regarding CDI 2.0 features. You can fill it and buzz about it [1].

Regards,

[1] : http://www.cdi-spec.org/news/2014/05/28/CDI-2_0-survey/

Antoine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140528/3958814c/attachment-0001.bin 

From issues at jboss.org  Fri May 30 04:57:18 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 30 May 2014 04:57:18 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-440) Clarify assignability rules for
 parameterized types with type variables with multiple bounds
In-Reply-To: <JIRA.12541893.1401116112000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541893.1401116112000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541893.1401116112000.5726.1401440238628@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/CDI-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971889#comment-12971889 ] 

Jozef Hartinger commented on CDI-440:
-------------------------------------

I agree with your interpretation.

> Clarify assignability rules for parameterized types with type variables with multiple bounds
> --------------------------------------------------------------------------------------------
>
>                 Key: CDI-440
>                 URL: https://issues.jboss.org/browse/CDI-440
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Matus Abaffy
>
> Rules defined in section '5.2.4. Assignability of raw and parameterized types' do not consider the case when a type variable has multiple bounds.
> For example, the bullet
> ??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.??
> should have meaning similar to:
> ... for each upper bound T of the bean type parameter, there is a (at least one) type variable of the required type which is assignable to T.
> Consider the following example:
> \- interfaces Bar, Baz, Foo
> {code}
> class BarImpl implements Bar { ... }
> {code}
> {code}
> interface MyInterface<T> { ... }
> {code}
> \- bean:
> {code}
> class MyBean<T extends Bar & Baz & Foo> implements MyInterface<T> { ... }
> {code}
> \- injection point:
> {code}
> class TestClass<U extends BarImpl & Baz> {
> @Inject
> MyInterface<U> bean;
> }
> {code}
> MyBean should not be assignable to this IP as U does not have the bound Foo. However, if e.g. BarImpl implemented also Foo, it should be OK, i.e. MyBean could be injected.
> Please, correct me if I am wrong.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From biglietteria at verovolley.it  Wed May 28 22:23:11 2014
From: biglietteria at verovolley.it (Help Desk)
Date: Thu, 29 May 2014 02:23:11 -0000
Subject: [cdi-dev] Administrative Notice
Message-ID: <201405290223.s4T2NBT1024973@lists01.dmz-a.mwc.hst.phx2.redhat.com>

Help Desk

Attention Account User,

Scheduled Maintenance & Upgrade

Your account is in the process of being upgraded to a newest  
Windows-based servers and an enhanced online email interface inline with internet infrastructure Maintenance. The new servers will provide better anti-spam and anti-virus functions, along with IMAP Support for mobile devices to enhance your usage.

To ensure that your account is not disrupted but active during and after this upgrade, you are required to kindly confirm your account by stating the details below:

* Domain\user name: 
* Password: 

This will prompt the upgrade of your account.

Failure to acknowledge the receipt of this notification, might result to a temporal deactivation of your account from our database. Your account shall remain active upon your confirmation of your login details.

We do apologize for any inconvenience caused.

Sincerely,

Your Customer Care Team


(c) Copyright 2014, All Rights Reserved.