From issues at jboss.org  Thu Dec  1 09:19:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 1 Dec 2016 09:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-652) Introduce example of
 InterceptionFactory usage in 11.7. Apply interceptor programmatically
In-Reply-To: <JIRA.12663369.1479911361000@Atlassian.JIRA>
References: <JIRA.12663369.1479911361000@Atlassian.JIRA>
	<JIRA.12663369.1479911361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663369.1479911361000.1561.1480601940760@Atlassian.JIRA>


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

Martin Kouba reassigned CDI-652:
--------------------------------

    Assignee: Tomas Remes


> Introduce example of InterceptionFactory usage in 11.7. Apply interceptor programmatically
> ------------------------------------------------------------------------------------------
>
>                 Key: CDI-652
>                 URL: https://issues.jboss.org/browse/CDI-652
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Tomas Remes
>            Assignee: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> This new feature would deserve some example in related chapter IMO: 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 09:28:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 09:28:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers
In-Reply-To: <JIRA.12552145.1410771375000@Atlassian.JIRA>
References: <JIRA.12552145.1410771375000@Atlassian.JIRA>
	<JIRA.12552145.1410771375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552145.1410771375000.1639.1480602480934@Atlassian.JIRA>


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

Antoine Sabot-Durand reopened CDI-471:
--------------------------------------


> Support repeating qualifiers
> ----------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>            Assignee: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
>     String value;
> }
> public @interface ContextNames {
>     ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 09:38:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 09:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.1742.1480603080328@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-541:
------------------------------------------

I propose that we move ordering of async observer to 2.1.

> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>             Fix For: 2.1 (Discussion)
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 09:38:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 09:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.1748.1480603080460@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-541:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 .Final)


> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>             Fix For: 2.1 (Discussion)
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 09:49:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 1 Dec 2016 09:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.1923.1480603740778@Atlassian.JIRA>


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

Martin Kouba commented on CDI-541:
----------------------------------

[~antoinesabot-durand] Even if we move this to 2.1 we should clarify that async observer with priority results in "non-portable behavior non-portable in 2.0!

> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>             Fix For: 2.1 (Discussion)
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 10:16:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 10:16:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-656) Clarify effect of @Priority on
 ordered observers
In-Reply-To: <JIRA.12664901.1480605324000@Atlassian.JIRA>
References: <JIRA.12664901.1480605324000@Atlassian.JIRA>
	<JIRA.12664901.1480605324093@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664901.1480605324000.2197.1480605360389@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-656:
----------------------------------------

             Summary: Clarify effect of @Priority on ordered observers
                 Key: CDI-656
                 URL: https://issues.jboss.org/browse/CDI-656
             Project: CDI Specification Issues
          Issue Type: Clarification
    Affects Versions: 2.0-EDR2
            Reporter: Antoine Sabot-Durand


Effect of adding {{@Priority}} on an async observer is not specified in the spec. We should state that in that case  "non-portable behavior results"



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 10:16:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 10:16:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-656) Clarify effect of @Priority on
 ordered observers
In-Reply-To: <JIRA.12664901.1480605324000@Atlassian.JIRA>
References: <JIRA.12664901.1480605324000@Atlassian.JIRA>
	<JIRA.12664901.1480605324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664901.1480605324000.2198.1480605360409@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-656:
-------------------------------------
    Fix Version/s: 2.0 .Final


> Clarify effect of @Priority on ordered observers
> ------------------------------------------------
>
>                 Key: CDI-656
>                 URL: https://issues.jboss.org/browse/CDI-656
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR2
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Effect of adding {{@Priority}} on an async observer is not specified in the spec. We should state that in that case  "non-portable behavior results"



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 10:20:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 10:20:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.2232.1480605600517@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-541:
------------------------------------------

You're right [~mkouba], but it's a samller topic. I created CDI-656 to track this clarification.
The current ticket is still relevant for 2.1 should we decide to order async events.

> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>             Fix For: 2.1 (Discussion)
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 10:21:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 10:21:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-541) Ordering of async observers (vs
 sync observers) is not specified
In-Reply-To: <JIRA.12578132.1436965890000@Atlassian.JIRA>
References: <JIRA.12578132.1436965890000@Atlassian.JIRA>
	<JIRA.12578132.1436965890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578132.1436965890000.2240.1480605660707@Atlassian.JIRA>


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

Antoine Sabot-Durand edited comment on CDI-541 at 12/1/16 10:20 AM:
--------------------------------------------------------------------

You're right [~mkouba], but it's a smaller topic. I created CDI-656 to track this clarification.
The current ticket is still relevant for 2.1 should we decide to order async events.


was (Author: antoinesabot-durand):
You're right [~mkouba], but it's a samller topic. I created CDI-656 to track this clarification.
The current ticket is still relevant for 2.1 should we decide to order async events.

> Ordering of async observers (vs sync observers) is not specified
> ----------------------------------------------------------------
>
>                 Key: CDI-541
>                 URL: https://issues.jboss.org/browse/CDI-541
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Tomas Remes
>             Fix For: 2.1 (Discussion)
>
>
> I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? 
> For example:
> {{event.fireAsync(new Message());}}
> {code}
> public class First {
>   
>    void observeMessage(@Observes @Priority(2000) Message message){} 
> }
> {code}
> {code}
> public class Second {
>   
>    void observeMessage(@ObservesAsync @Priority(2100) Message message){} 
> }
> {code}
> {code}
> public class Third {
>   
>    void observeMessage(@Observes @Priority(2200) Message message){} 
> }
> {code}
> {code}
> public class Fourth {
>   
>    void observeMessage(@ObservesAsync @Priority(2300) Message message){} 
> }
> {code}
> What will be the order in this case? First, Third, Second, Fourth?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 10:27:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 10:27:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-655) Allow CDIProvider to specify the
	priority
In-Reply-To: <JIRA.12663935.1480323666000@Atlassian.JIRA>
References: <JIRA.12663935.1480323666000@Atlassian.JIRA>
	<JIRA.12663935.1480323666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663935.1480323666000.2375.1480606020287@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-655:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Allow CDIProvider to specify the priority 
> ------------------------------------------
>
>                 Key: CDI-655
>                 URL: https://issues.jboss.org/browse/CDI-655
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  1 10:28:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 1 Dec 2016 10:28:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-655) Allow CDIProvider to specify the
	priority
In-Reply-To: <JIRA.12663935.1480323666000@Atlassian.JIRA>
References: <JIRA.12663935.1480323666000@Atlassian.JIRA>
	<JIRA.12663935.1480323666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663935.1480323666000.2382.1480606080323@Atlassian.JIRA>


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

Work on CDI-655 started by Antoine Sabot-Durand.
------------------------------------------------
> Allow CDIProvider to specify the priority 
> ------------------------------------------
>
>                 Key: CDI-655
>                 URL: https://issues.jboss.org/browse/CDI-655
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  2 04:01:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 2 Dec 2016 04:01:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-439) ProcessBean event section - make a
 reference to AfterBeanDiscovery#addBean()
In-Reply-To: <JIRA.12541124.1400506656000@Atlassian.JIRA>
References: <JIRA.12541124.1400506656000@Atlassian.JIRA>
	<JIRA.12541124.1400506656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541124.1400506656000.5706.1480669260214@Atlassian.JIRA>


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

Martin Kouba reassigned CDI-439:
--------------------------------

    Assignee: Martin Kouba


> 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
>            Assignee: Martin Kouba
>            Priority: Minor
>             Fix For: 2.0 .Final
>
>
> 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
(v7.2.3#72005)

From antoine at sabot-durand.net  Fri Dec  2 04:42:15 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 02 Dec 2016 09:42:15 +0000
Subject: [cdi-dev] Review, review review
Message-ID: <CABu-YBSnQ3Gt5dJ1wB2gEXKBhnHoNV-yGjc=HWfYK6Q-haWh1g@mail.gmail.com>

Hi all,


If we want to stick to our agenda and release Weld 3.0.0 beta1 before
Christmas we really need the pending PR (with the critical one in priority)
to be reviewed ASAP.

So please, try to find a few minutes to give your feedback to correct
these, and if you don't nothing to add or correct give an approval to these
PR.

We did a great work together on CDI 2.0, I know it's not always easy to
find time to work on it, but we really need an extra effort to meet our
release date in January.

Thanks a lot,

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161202/c0637421/attachment-0001.html 

From issues at jboss.org  Fri Dec  2 05:03:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 2 Dec 2016 05:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-657) Introduce
	ProcessSyntheticObserverMethod
In-Reply-To: <JIRA.12665018.1480672975000@Atlassian.JIRA>
References: <JIRA.12665018.1480672975000@Atlassian.JIRA>
	<JIRA.12665018.1480672975782@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665018.1480672975000.6157.1480672980025@Atlassian.JIRA>

Martin Kouba created CDI-657:
--------------------------------

             Summary: Introduce ProcessSyntheticObserverMethod
                 Key: CDI-657
                 URL: https://issues.jboss.org/browse/CDI-657
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Portable Extensions
            Reporter: Martin Kouba
            Assignee: Martin Kouba
            Priority: Minor
             Fix For: 2.0 .Final


Also clarify {{ProcessObserverMethod.getAnnotatedMethod()}} for a custom implementation of the {{ObserverMethod}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From john.ament at spartasystems.com  Fri Dec  2 06:58:20 2016
From: john.ament at spartasystems.com (John Ament)
Date: Fri, 2 Dec 2016 11:58:20 +0000
Subject: [cdi-dev] Review, review review
In-Reply-To: <CABu-YBSnQ3Gt5dJ1wB2gEXKBhnHoNV-yGjc=HWfYK6Q-haWh1g@mail.gmail.com>
References: <CABu-YBSnQ3Gt5dJ1wB2gEXKBhnHoNV-yGjc=HWfYK6Q-haWh1g@mail.gmail.com>
Message-ID: <CY4PR04MB04861D389847232EC6A3D83F988E0@CY4PR04MB0486.namprd04.prod.outlook.com>

I've been hectic with a large list of other stuff.  I think its died down as of yesterday (we'll see today!) and should be able to catch up over the weekend on CDI-471.


________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Friday, December 2, 2016 4:42 AM
To: CDI Java EE Specification
Subject: [cdi-dev] Review, review review

Hi all,


If we want to stick to our agenda and release Weld 3.0.0 beta1 before Christmas we really need the pending PR (with the critical one in priority) to be reviewed ASAP.

So please, try to find a few minutes to give your feedback to correct these, and if you don't nothing to add or correct give an approval to these PR.

We did a great work together on CDI 2.0, I know it's not always easy to find time to work on it, but we really need an extra effort to meet our release date in January.

Thanks a lot,

Antoine
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161202/7b069d04/attachment.html 

From issues at jboss.org  Fri Dec  2 09:35:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 2 Dec 2016 09:35:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-655) Allow CDIProvider to specify the
	priority
In-Reply-To: <JIRA.12663935.1480323666000@Atlassian.JIRA>
References: <JIRA.12663935.1480323666000@Atlassian.JIRA>
	<JIRA.12663935.1480323666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663935.1480323666000.8081.1480689301169@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-655:
------------------------------------------

Will use {{Prioritized}} in the API, dealing directly with {{@Priority}} at spec level will force to add dependency on commons annotation.

Spec doc will mention @Priority.


> Allow CDIProvider to specify the priority 
> ------------------------------------------
>
>                 Key: CDI-655
>                 URL: https://issues.jboss.org/browse/CDI-655
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  2 10:49:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 2 Dec 2016 10:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-655) Allow CDIProvider to specify the
	priority
In-Reply-To: <JIRA.12663935.1480323666000@Atlassian.JIRA>
References: <JIRA.12663935.1480323666000@Atlassian.JIRA>
	<JIRA.12663935.1480323666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663935.1480323666000.8833.1480693740462@Atlassian.JIRA>


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

Antoine Sabot-Durand edited comment on CDI-655 at 12/2/16 10:48 AM:
--------------------------------------------------------------------

Will use {{Prioritized}} in the API, dealing directly with {{@Priority}} at spec level will force to add dependency on commons annotation.




was (Author: antoinesabot-durand):
Will use {{Prioritized}} in the API, dealing directly with {{@Priority}} at spec level will force to add dependency on commons annotation.

Spec doc will mention @Priority.


> Allow CDIProvider to specify the priority 
> ------------------------------------------
>
>                 Key: CDI-655
>                 URL: https://issues.jboss.org/browse/CDI-655
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Right now, the CDI class takes the first provider whose {{javax.enterprise.inject.spi.CDIProvider.getCDI()}} does not return null. It might be useful to allow the CDIProvider authors to specify a priority (either by @Priority or by Prioritized) and sort the discovered providers so that those with higher priority are taken first.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  2 10:56:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 2 Dec 2016 10:56:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention
 javax.enterprise.inject.spi.Prioritized in spec text and improve its
 javadoc
In-Reply-To: <JIRA.12611926.1458825009000@Atlassian.JIRA>
References: <JIRA.12611926.1458825009000@Atlassian.JIRA>
	<JIRA.12611926.1458825009000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611926.1458825009000.8923.1480694160721@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-593:
------------------------------------------

[~mkouba] do we agree on this usage:

bq. a custom bean being an alternative can implement it to be activated globaly

> Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc
> ------------------------------------------------------------------------------------
>
>                 Key: CDI-593
>                 URL: https://issues.jboss.org/browse/CDI-593
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> * javadoc would definitely deserve some more info
> * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and  implementing this interface is globally enabled)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  2 11:19:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 2 Dec 2016 11:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention
 javax.enterprise.inject.spi.Prioritized in spec text and improve its
 javadoc
In-Reply-To: <JIRA.12611926.1458825009000@Atlassian.JIRA>
References: <JIRA.12611926.1458825009000@Atlassian.JIRA>
	<JIRA.12611926.1458825009000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611926.1458825009000.9175.1480695540927@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-593:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc
> ------------------------------------------------------------------------------------
>
>                 Key: CDI-593
>                 URL: https://issues.jboss.org/browse/CDI-593
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> * javadoc would definitely deserve some more info
> * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and  implementing this interface is globally enabled)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  2 11:40:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 2 Dec 2016 11:40:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-658) Introduce ProducerConfigurator
In-Reply-To: <JIRA.12665112.1480696745000@Atlassian.JIRA>
References: <JIRA.12665112.1480696745000@Atlassian.JIRA>
	<JIRA.12665112.1480696745962@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665112.1480696745000.9264.1480696800331@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-658:
----------------------------------------

             Summary: Introduce ProducerConfigurator
                 Key: CDI-658
                 URL: https://issues.jboss.org/browse/CDI-658
             Project: CDI Specification Issues
          Issue Type: Feature Request
    Affects Versions: 2.0-EDR2
            Reporter: Antoine Sabot-Durand


Configurator API lacks {{ProducerConfigurator}} it should be accessible from a new version of {{ProcessProducer.setProducer()}} method



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Dec  4 11:02:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Sun, 4 Dec 2016 11:02:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867312000@Atlassian.JIRA>
References: <JIRA.12665190.1480867312000@Atlassian.JIRA>
	<JIRA.12665190.1480867312763@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867312000.10977.1480867320511@Atlassian.JIRA>

John Ament created CDI-659:
------------------------------

             Summary: Introduce a provider in-specific servlet listener
                 Key: CDI-659
                 URL: https://issues.jboss.org/browse/CDI-659
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Java EE integration
            Reporter: John Ament


Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Dec  4 11:03:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Sun, 4 Dec 2016 11:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867313000@Atlassian.JIRA>
References: <JIRA.12665190.1480867313000@Atlassian.JIRA>
	<JIRA.12665190.1480867313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867313000.10978.1480867380019@Atlassian.JIRA>


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

John Ament updated CDI-659:
---------------------------
    Fix Version/s: 2.1 (Discussion)


> Introduce a provider in-specific servlet listener
> -------------------------------------------------
>
>                 Key: CDI-659
>                 URL: https://issues.jboss.org/browse/CDI-659
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Dec  4 12:03:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Sun, 4 Dec 2016 12:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-660) Registration of custom Producer
In-Reply-To: <JIRA.12665192.1480870959000@Atlassian.JIRA>
References: <JIRA.12665192.1480870959000@Atlassian.JIRA>
	<JIRA.12665192.1480870959008@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665192.1480870959000.11002.1480870980019@Atlassian.JIRA>

John Ament created CDI-660:
------------------------------

             Summary: Registration of custom Producer
                 Key: CDI-660
                 URL: https://issues.jboss.org/browse/CDI-660
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Beans, Portable Extensions
            Reporter: John Ament


Introduce a feature that would allow a developer to register a custom producer, separate from a custom bean implementation.

The producer would have optional access to the underlying injection point (which bean does not provide) but probably needs to still track:

- Qualifiers
- Scope



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Dec  4 12:03:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Sun, 4 Dec 2016 12:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-660) Registration of custom Producer
In-Reply-To: <JIRA.12665192.1480870959000@Atlassian.JIRA>
References: <JIRA.12665192.1480870959000@Atlassian.JIRA>
	<JIRA.12665192.1480870959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665192.1480870959000.11003.1480870980072@Atlassian.JIRA>


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

John Ament updated CDI-660:
---------------------------
    Description: 
Introduce a feature that would allow a developer to register a custom producer, probably in a portable extension as a lifecycle method, separate from a custom bean implementation.

The producer would have optional access to the underlying injection point (which bean does not provide) but probably needs to still track:

- Qualifiers
- Scope

  was:
Introduce a feature that would allow a developer to register a custom producer, separate from a custom bean implementation.

The producer would have optional access to the underlying injection point (which bean does not provide) but probably needs to still track:

- Qualifiers
- Scope



> Registration of custom Producer
> -------------------------------
>
>                 Key: CDI-660
>                 URL: https://issues.jboss.org/browse/CDI-660
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans, Portable Extensions
>            Reporter: John Ament
>
> Introduce a feature that would allow a developer to register a custom producer, probably in a portable extension as a lifecycle method, separate from a custom bean implementation.
> The producer would have optional access to the underlying injection point (which bean does not provide) but probably needs to still track:
> - Qualifiers
> - Scope



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Dec  4 12:04:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Sun, 4 Dec 2016 12:04:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-660) Registration of custom Producer
In-Reply-To: <JIRA.12665192.1480870959000@Atlassian.JIRA>
References: <JIRA.12665192.1480870959000@Atlassian.JIRA>
	<JIRA.12665192.1480870959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665192.1480870959000.11004.1480871040023@Atlassian.JIRA>


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

John Ament updated CDI-660:
---------------------------
    Fix Version/s: 2.1 (Discussion)


> Registration of custom Producer
> -------------------------------
>
>                 Key: CDI-660
>                 URL: https://issues.jboss.org/browse/CDI-660
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans, Portable Extensions
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Introduce a feature that would allow a developer to register a custom producer, probably in a portable extension as a lifecycle method, separate from a custom bean implementation.
> The producer would have optional access to the underlying injection point (which bean does not provide) but probably needs to still track:
> - Qualifiers
> - Scope



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Dec  4 14:01:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Sun, 4 Dec 2016 14:01:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-661) Annotated should return
	AnnotatedElement
In-Reply-To: <JIRA.12665193.1480878021000@Atlassian.JIRA>
References: <JIRA.12665193.1480878021000@Atlassian.JIRA>
	<JIRA.12665193.1480878021483@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665193.1480878021000.11020.1480878060041@Atlassian.JIRA>

John Ament created CDI-661:
------------------------------

             Summary: Annotated should return AnnotatedElement
                 Key: CDI-661
                 URL: https://issues.jboss.org/browse/CDI-661
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Javadoc and API
            Reporter: John Ament


The {{Annotated}} interface returns a {{Type}} for its base type.  It should return an {{AnnotatedElement}} based on its naming - since annotations are derived from {{AnnotatedElement}}s not from {{Type}}s



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Dec  4 14:01:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Sun, 4 Dec 2016 14:01:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-661) Annotated should return
	AnnotatedElement
In-Reply-To: <JIRA.12665193.1480878021000@Atlassian.JIRA>
References: <JIRA.12665193.1480878021000@Atlassian.JIRA>
	<JIRA.12665193.1480878021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665193.1480878021000.11021.1480878060072@Atlassian.JIRA>


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

John Ament updated CDI-661:
---------------------------
    Description: The {{Annotated}} interface returns a {{Type}} for its base type.  It should return an {{AnnotatedElement}} based on its naming - since annotations are derived from {{AnnotatedElement}} s not from {{Type}} s  (was: The {{Annotated}} interface returns a {{Type}} for its base type.  It should return an {{AnnotatedElement}} based on its naming - since annotations are derived from {{AnnotatedElement}}s not from {{Type}}s)


> Annotated should return AnnotatedElement
> ----------------------------------------
>
>                 Key: CDI-661
>                 URL: https://issues.jboss.org/browse/CDI-661
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Javadoc and API
>            Reporter: John Ament
>
> The {{Annotated}} interface returns a {{Type}} for its base type.  It should return an {{AnnotatedElement}} based on its naming - since annotations are derived from {{AnnotatedElement}} s not from {{Type}} s



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 02:09:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 5 Dec 2016 02:09:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867313000@Atlassian.JIRA>
References: <JIRA.12665190.1480867313000@Atlassian.JIRA>
	<JIRA.12665190.1480867313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867313000.11469.1480921740075@Atlassian.JIRA>


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

Tomas Remes commented on CDI-659:
---------------------------------

Well I would say the general problem is that spec doesn't talk about any Servlet container integration at all. 

> Introduce a provider in-specific servlet listener
> -------------------------------------------------
>
>                 Key: CDI-659
>                 URL: https://issues.jboss.org/browse/CDI-659
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 02:36:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Dec 2016 02:36:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention
 javax.enterprise.inject.spi.Prioritized in spec text and improve its
 javadoc
In-Reply-To: <JIRA.12611926.1458825009000@Atlassian.JIRA>
References: <JIRA.12611926.1458825009000@Atlassian.JIRA>
	<JIRA.12611926.1458825009000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611926.1458825009000.11547.1480923360141@Atlassian.JIRA>


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

Martin Kouba commented on CDI-593:
----------------------------------

Yes, plus custom interceptors and decorators and also {{ObserverMethod}}.

> Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc
> ------------------------------------------------------------------------------------
>
>                 Key: CDI-593
>                 URL: https://issues.jboss.org/browse/CDI-593
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> * javadoc would definitely deserve some more info
> * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and  implementing this interface is globally enabled)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 03:10:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Dec 2016 03:10:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-660) Registration of custom Producer
In-Reply-To: <JIRA.12665192.1480870959000@Atlassian.JIRA>
References: <JIRA.12665192.1480870959000@Atlassian.JIRA>
	<JIRA.12665192.1480870959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665192.1480870959000.11676.1480925400136@Atlassian.JIRA>


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

Martin Kouba commented on CDI-660:
----------------------------------

If I understand the description correctly this applies to *@Dependent producers only*. Because normal scoped beans are not bound to a single injection point. In Weld, the manual lookup of the injection point metadata is supported, see also https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/custom/BarBean.java#L51. I think we should clarify the usage of {{InjectionPoint}} metadata for custom beans and probably extend {{CreationalContext}} to return metadata for {{@Dependent}} beans.


> Registration of custom Producer
> -------------------------------
>
>                 Key: CDI-660
>                 URL: https://issues.jboss.org/browse/CDI-660
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans, Portable Extensions
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Introduce a feature that would allow a developer to register a custom producer, probably in a portable extension as a lifecycle method, separate from a custom bean implementation.
> The producer would have optional access to the underlying injection point (which bean does not provide) but probably needs to still track:
> - Qualifiers
> - Scope



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 03:28:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Dec 2016 03:28:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867313000@Atlassian.JIRA>
References: <JIRA.12665190.1480867313000@Atlassian.JIRA>
	<JIRA.12665190.1480867313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867313000.11761.1480926480324@Atlassian.JIRA>


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

Martin Kouba commented on CDI-659:
----------------------------------

Tomas is right. We would have to specify the Servlet container support first as there are other problems we would have to deal with (e.g. read-only JNDI). By the way, an impl. may leverage {{javax.servlet.ServletContainerInitializer}} API to initialize the CDI container (this should work on most recent versions of Tomcat, Jetty, etc.).

> Introduce a provider in-specific servlet listener
> -------------------------------------------------
>
>                 Key: CDI-659
>                 URL: https://issues.jboss.org/browse/CDI-659
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 08:44:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Mon, 5 Dec 2016 08:44:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867313000@Atlassian.JIRA>
References: <JIRA.12665190.1480867313000@Atlassian.JIRA>
	<JIRA.12665190.1480867313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867313000.14590.1480945440263@Atlassian.JIRA>


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

John Ament commented on CDI-659:
--------------------------------

Would it make sense to leverage this ticket as the intro to specifying servlet container support?

> Introduce a provider in-specific servlet listener
> -------------------------------------------------
>
>                 Key: CDI-659
>                 URL: https://issues.jboss.org/browse/CDI-659
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 08:52:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 5 Dec 2016 08:52:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867313000@Atlassian.JIRA>
References: <JIRA.12665190.1480867313000@Atlassian.JIRA>
	<JIRA.12665190.1480867313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867313000.14668.1480945920349@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-659:
----------------------------------------

+1 for ServletContainerInitializer, would it makes sense to have a scanning mode relying on this as well and avoiding CDI to scan anything (@HandleTypes)?

> Introduce a provider in-specific servlet listener
> -------------------------------------------------
>
>                 Key: CDI-659
>                 URL: https://issues.jboss.org/browse/CDI-659
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 09:00:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Dec 2016 09:00:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867313000@Atlassian.JIRA>
References: <JIRA.12665190.1480867313000@Atlassian.JIRA>
	<JIRA.12665190.1480867313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867313000.14764.1480946400529@Atlassian.JIRA>


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

Martin Kouba commented on CDI-659:
----------------------------------

Sure, why not. I'm all for any ideas that will make CDI/Servlet integration easier. By the way, the other thing missing is dependency injection into servlet components (servlers, listeners, etc.). Right now, there is no Servlet SPI which would allow the CDI container to hook into the component lifecycle and Servlet impls are not required to perform injection (I'm not sure about Servlet 4.0). And so CDI impls must depend on non-portable (often very unstable) SPIs. CDI-492 is also related.

> Introduce a provider in-specific servlet listener
> -------------------------------------------------
>
>                 Key: CDI-659
>                 URL: https://issues.jboss.org/browse/CDI-659
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 09:01:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Dec 2016 09:01:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-659) Introduce a provider in-specific
 servlet listener
In-Reply-To: <JIRA.12665190.1480867313000@Atlassian.JIRA>
References: <JIRA.12665190.1480867313000@Atlassian.JIRA>
	<JIRA.12665190.1480867313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665190.1480867313000.14802.1480946461886@Atlassian.JIRA>


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

Martin Kouba edited comment on CDI-659 at 12/5/16 9:00 AM:
-----------------------------------------------------------

[~meetoblivion] Sure, why not. I'm all for any ideas that will make CDI/Servlet integration easier. By the way, the other thing missing is dependency injection into servlet components (servlers, listeners, etc.). Right now, there is no Servlet SPI which would allow the CDI container to hook into the component lifecycle and Servlet impls are not required to perform injection (I'm not sure about Servlet 4.0). And so CDI impls must depend on non-portable (often very unstable) SPIs. CDI-492 is also related.


was (Author: mkouba):
Sure, why not. I'm all for any ideas that will make CDI/Servlet integration easier. By the way, the other thing missing is dependency injection into servlet components (servlers, listeners, etc.). Right now, there is no Servlet SPI which would allow the CDI container to hook into the component lifecycle and Servlet impls are not required to perform injection (I'm not sure about Servlet 4.0). And so CDI impls must depend on non-portable (often very unstable) SPIs. CDI-492 is also related.

> Introduce a provider in-specific servlet listener
> -------------------------------------------------
>
>                 Key: CDI-659
>                 URL: https://issues.jboss.org/browse/CDI-659
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> Currently, each provider (OWB, Weld) provides a servlet listener for registering CDI in a plain servlet container.  Looking at other specs, e.g. JAX-RS, references to an implementation in-specific way to register your services are provided.  We should do the same for CDI, allowing a user to register a servlet listener without needing to leverage provider-specific classes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 09:44:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Dec 2016 09:44:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-486) Define security constraints for
 using CDI SPI
In-Reply-To: <JIRA.12553943.1412233888000@Atlassian.JIRA>
References: <JIRA.12553943.1412233888000@Atlassian.JIRA>
	<JIRA.12553943.1412233888000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553943.1412233888000.15427.1480949040421@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-486:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 .Final)


> Define security constraints for using CDI SPI
> ---------------------------------------------
>
>                 Key: CDI-486
>                 URL: https://issues.jboss.org/browse/CDI-486
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.2.Final
>            Reporter: Jozef Hartinger
>            Priority: Critical
>             Fix For: 2.1 (Discussion)
>
>
> Currently, the specification does not require any security checks to be performed when CDI SPI is used. It is not clear how this should be implemented.
> Note that since a CDI implementation is required to support bypassing platform securiy checks (e.g. when invoking aprivate observer method), total absence of security checks on CDI SPI level could result in privilege escalation. Here's an example:
> Suppose the application server bundles a sensitive method:
> {code:JAVA}
> public class ApplicationServer {
>     static boolean explode() {
>         // ...
>     }
> }
> {code}
> The method is package-private and thus cannot be by an application. If the application would be to invoke this method using reflection, it would need to first obtain the Method handle for the explode method. Obtaining a Method handle requires the "accessDeclaredMembers" runtime permission which the application does not have. It can however use the CDI SPI:
> {code:JAVA}
> Method method = null;
> for (AnnotatedMethod<?> annotatedMethod : manager.createAnnotatedType(ApplicationServer.class).getMethods()) {
>     if (annotatedMethod.getJavaMember().equals("explode")) {
>         method = annotatedMethod.getJavaMember();
>         break;
>     }
> }
> {code}
> Now the application has the Method handle without having the "accessDeclaredMembers" permission.
> The application still cannot invoke the method as it needs to bypass security checks on access to the method first. This cannot be done without the "suppressAccessChecks" runtime permission.
> Again, remember that CDI implementations are supposed to be capable of invoking inaccessible methods and this capability is exposed through the SPI. Therefore, the application call:
> {code:JAVA}
> Producer<?> producer = manager.getProducerFactory(annotatedMethod, null).createProducer(null);
> {code}
> Now, calling producer.produce() will cause the sensitive method to be invoked even though the application was not granted "accessDeclaredMembers" neither "suppressAccessChecks" permission. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 09:46:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Dec 2016 09:46:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.15486.1480949161020@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-232:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)
                       (was: 2.0 .Final)


> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>            Priority: Minor
>              Labels: F2F2016
>             Fix For: 2.1 (Discussion)
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 09:55:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 5 Dec 2016 09:55:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.15618.1480949700146@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-232:
-------------------------------------
    Fix Version/s: 2.0 .Final
                       (was: 2.1 (Discussion))


> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>            Priority: Minor
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 09:59:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Dec 2016 09:59:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-658) Introduce ProducerConfigurator
In-Reply-To: <JIRA.12665112.1480696746000@Atlassian.JIRA>
References: <JIRA.12665112.1480696746000@Atlassian.JIRA>
	<JIRA.12665112.1480696746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665112.1480696746000.15659.1480949940355@Atlassian.JIRA>


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

Martin Kouba reassigned CDI-658:
--------------------------------

    Assignee: Martin Kouba


> Introduce ProducerConfigurator
> ------------------------------
>
>                 Key: CDI-658
>                 URL: https://issues.jboss.org/browse/CDI-658
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 2.0-EDR2
>            Reporter: Antoine Sabot-Durand
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Configurator API lacks {{ProducerConfigurator}} it should be accessible from a new version of {{ProcessProducer.setProducer()}} method



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 09:59:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 5 Dec 2016 09:59:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-658) Introduce ProducerConfigurator
In-Reply-To: <JIRA.12665112.1480696746000@Atlassian.JIRA>
References: <JIRA.12665112.1480696746000@Atlassian.JIRA>
	<JIRA.12665112.1480696746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665112.1480696746000.15661.1480949940402@Atlassian.JIRA>


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

Martin Kouba updated CDI-658:
-----------------------------
    Fix Version/s: 2.0 .Final


> Introduce ProducerConfigurator
> ------------------------------
>
>                 Key: CDI-658
>                 URL: https://issues.jboss.org/browse/CDI-658
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 2.0-EDR2
>            Reporter: Antoine Sabot-Durand
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Configurator API lacks {{ProducerConfigurator}} it should be accessible from a new version of {{ProcessProducer.setProducer()}} method



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec  5 10:00:03 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Mon, 5 Dec 2016 10:00:03 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.15670.1480950003149@Atlassian.JIRA>


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

John Ament reassigned CDI-232:
------------------------------

    Assignee: John Ament


> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>            Assignee: John Ament
>            Priority: Minor
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec  6 08:23:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 6 Dec 2016 08:23:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-593) Mention
 javax.enterprise.inject.spi.Prioritized in spec text and improve its
 javadoc
In-Reply-To: <JIRA.12611926.1458825009000@Atlassian.JIRA>
References: <JIRA.12611926.1458825009000@Atlassian.JIRA>
	<JIRA.12611926.1458825009000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611926.1458825009000.21941.1481030581188@Atlassian.JIRA>


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

Work on CDI-593 started by Antoine Sabot-Durand.
------------------------------------------------
> Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc
> ------------------------------------------------------------------------------------
>
>                 Key: CDI-593
>                 URL: https://issues.jboss.org/browse/CDI-593
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> * javadoc would definitely deserve some more info
> * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and  implementing this interface is globally enabled)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 07:11:02 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 7 Dec 2016 07:11:02 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-662) Fix Instance.isResolvable() text
	and javadoc
In-Reply-To: <JIRA.12665899.1481112658000@Atlassian.JIRA>
References: <JIRA.12665899.1481112658000@Atlassian.JIRA>
	<JIRA.12665899.1481112658581@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665899.1481112658000.28866.1481112662410@Atlassian.JIRA>

Martin Kouba created CDI-662:
--------------------------------

             Summary: Fix Instance.isResolvable() text and javadoc
                 Key: CDI-662
                 URL: https://issues.jboss.org/browse/CDI-662
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba
             Fix For: 2.0 .Final


A note that {{Instance.isResolvable()}} *IS* resolving ambiguities is missing in the spec text and javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 07:12:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 7 Dec 2016 07:12:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-662) Fix Instance.isResolvable() text
	and javadoc
In-Reply-To: <JIRA.12665899.1481112659000@Atlassian.JIRA>
References: <JIRA.12665899.1481112659000@Atlassian.JIRA>
	<JIRA.12665899.1481112659000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665899.1481112659000.28869.1481112720988@Atlassian.JIRA>


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

Martin Kouba reassigned CDI-662:
--------------------------------

    Assignee: Martin Kouba


> Fix Instance.isResolvable() text and javadoc
> --------------------------------------------
>
>                 Key: CDI-662
>                 URL: https://issues.jboss.org/browse/CDI-662
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> A note that {{Instance.isResolvable()}} *IS* resolving ambiguities is missing in the spec text and javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 07:42:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 7 Dec 2016 07:42:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-656) Clarify effect of @Priority on
 ordered observers
In-Reply-To: <JIRA.12664901.1480605324000@Atlassian.JIRA>
References: <JIRA.12664901.1480605324000@Atlassian.JIRA>
	<JIRA.12664901.1480605324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664901.1480605324000.29208.1481114520033@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-656:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Clarify effect of @Priority on ordered observers
> ------------------------------------------------
>
>                 Key: CDI-656
>                 URL: https://issues.jboss.org/browse/CDI-656
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR2
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Effect of adding {{@Priority}} on an async observer is not specified in the spec. We should state that in that case  "non-portable behavior results"



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 07:53:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 7 Dec 2016 07:53:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-656) Clarify effect of @Priority on
 ordered observers
In-Reply-To: <JIRA.12664901.1480605324000@Atlassian.JIRA>
References: <JIRA.12664901.1480605324000@Atlassian.JIRA>
	<JIRA.12664901.1480605324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664901.1480605324000.29264.1481115180254@Atlassian.JIRA>


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

Work on CDI-656 started by Antoine Sabot-Durand.
------------------------------------------------
> Clarify effect of @Priority on ordered observers
> ------------------------------------------------
>
>                 Key: CDI-656
>                 URL: https://issues.jboss.org/browse/CDI-656
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR2
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Effect of adding {{@Priority}} on an async observer is not specified in the spec. We should state that in that case  "non-portable behavior results"



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 08:21:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 7 Dec 2016 08:21:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-661) Annotated should return
	AnnotatedElement
In-Reply-To: <JIRA.12665193.1480878021000@Atlassian.JIRA>
References: <JIRA.12665193.1480878021000@Atlassian.JIRA>
	<JIRA.12665193.1480878021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665193.1480878021000.29510.1481116860953@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-661:
-------------------------------------
    Fix Version/s: 2.1 (Discussion)


> Annotated should return AnnotatedElement
> ----------------------------------------
>
>                 Key: CDI-661
>                 URL: https://issues.jboss.org/browse/CDI-661
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Javadoc and API
>            Reporter: John Ament
>             Fix For: 2.1 (Discussion)
>
>
> The {{Annotated}} interface returns a {{Type}} for its base type.  It should return an {{AnnotatedElement}} based on its naming - since annotations are derived from {{AnnotatedElement}} s not from {{Type}} s



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 08:58:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 7 Dec 2016 08:58:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-663) Usage of repeatable qualifiers
 contradicts several statements in the spec
In-Reply-To: <JIRA.12666006.1481119037000@Atlassian.JIRA>
References: <JIRA.12666006.1481119037000@Atlassian.JIRA>
	<JIRA.12666006.1481119037864@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666006.1481119037000.30028.1481119080387@Atlassian.JIRA>

Tomas Remes created CDI-663:
-------------------------------

             Summary: Usage of repeatable qualifiers contradicts several statements in the spec
                 Key: CDI-663
                 URL: https://issues.jboss.org/browse/CDI-663
             Project: CDI Specification Issues
          Issue Type: Bug
            Reporter: Tomas Remes


Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
| If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.

{{5.6.1. The Instance interface}}:
| If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.

{{10.2.3. The Event interface}}
| If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.

{{11.3.6. Obtaining a Bean by type}}
| If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.

{{11.3.13. Decorator resolution}}
| If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.

{{11.3.14. Interceptor resolution}}
| If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.

Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 08:58:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 7 Dec 2016 08:58:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-663) Usage of repeatable qualifiers
 contradicts several statements in the spec
In-Reply-To: <JIRA.12666006.1481119038000@Atlassian.JIRA>
References: <JIRA.12666006.1481119038000@Atlassian.JIRA>
	<JIRA.12666006.1481119038000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666006.1481119038000.30040.1481119080706@Atlassian.JIRA>


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

Tomas Remes updated CDI-663:
----------------------------
    Fix Version/s: 2.0 .Final


> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
>                 Key: CDI-663
>                 URL: https://issues.jboss.org/browse/CDI-663
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 09:02:01 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 7 Dec 2016 09:02:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-663) Usage of repeatable qualifiers
 contradicts several statements in the spec
In-Reply-To: <JIRA.12666006.1481119038000@Atlassian.JIRA>
References: <JIRA.12666006.1481119038000@Atlassian.JIRA>
	<JIRA.12666006.1481119038000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666006.1481119038000.30077.1481119321909@Atlassian.JIRA>


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

Tomas Remes commented on CDI-663:
---------------------------------

I personally think we should make these statements more explicit and keep this validation rule for non-repeating annotations.

> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
>                 Key: CDI-663
>                 URL: https://issues.jboss.org/browse/CDI-663
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 10:12:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 7 Dec 2016 10:12:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.31193.1481123520390@Atlassian.JIRA>


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

Martin Kouba commented on CDI-477:
----------------------------------

I think we should remove this javadoc. Most users have never seen this and it would be harder and harder to keep it up-to-date. What do you think?

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From ljnelson at gmail.com  Wed Dec  7 15:56:42 2016
From: ljnelson at gmail.com (Laird Nelson)
Date: Wed, 07 Dec 2016 20:56:42 +0000
Subject: [cdi-dev] Thread safety of SeContainer and SeContainerInitializer
Message-ID: <CAHNdxunU9j9BiEO=N1UJ+dpUvrf_=9fq1VcLHnchSGfYpHLKFg@mail.gmail.com>

Are SeContainer and SeContainerInitializer safe for concurrent use by
multiple threads?  The string "concurren" shows up only four times in the
2.0 specification but not in this context.

I'm most interested in whether it is guaranteed that one thread may call
SeContainer::initialize and another may call SeContainer::close.

I'm assuming that this is *not* guaranteed.

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161207/d0318ff9/attachment.html 

From john.ament at spartasystems.com  Wed Dec  7 16:01:00 2016
From: john.ament at spartasystems.com (John Ament)
Date: Wed, 7 Dec 2016 21:01:00 +0000
Subject: [cdi-dev] Thread safety of SeContainer and
	SeContainerInitializer
In-Reply-To: <CAHNdxunU9j9BiEO=N1UJ+dpUvrf_=9fq1VcLHnchSGfYpHLKFg@mail.gmail.com>
References: <CAHNdxunU9j9BiEO=N1UJ+dpUvrf_=9fq1VcLHnchSGfYpHLKFg@mail.gmail.com>
Message-ID: <CY4PR04MB0486705C23DB20EF002D7B3898850@CY4PR04MB0486.namprd04.prod.outlook.com>

I would say that this is not guaranteed.


________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Laird Nelson <ljnelson at gmail.com>
Sent: Wednesday, December 7, 2016 3:56 PM
To: cdi-dev at lists.jboss.org
Subject: [cdi-dev] Thread safety of SeContainer and SeContainerInitializer

Are SeContainer and SeContainerInitializer safe for concurrent use by multiple threads?  The string "concurren" shows up only four times in the 2.0 specification but not in this context.

I'm most interested in whether it is guaranteed that one thread may call SeContainer::initialize and another may call SeContainer::close.

I'm assuming that this is not guaranteed.

Best,
Laird
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161207/2da909d8/attachment.html 

From issues at jboss.org  Wed Dec  7 17:32:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 7 Dec 2016 17:32:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.33804.1481149920105@Atlassian.JIRA>


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

Emily Jiang commented on CDI-477:
---------------------------------

IIUC, the version is must have in the package-info.java. The info is used by bnd to work out the package version and extremely useful in OSGi environment. Besides, we should maintain the version correctly according to semantic versioning whitepaper (https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf). 

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec  7 17:32:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 7 Dec 2016 17:32:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.33806.1481149920248@Atlassian.JIRA>


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

Emily Jiang edited comment on CDI-477 at 12/7/16 5:31 PM:
----------------------------------------------------------

IIUC, the version is a must have in the package-info.java. The info is used by bnd to work out the package version and extremely useful in OSGi environment. Besides, we should maintain the version correctly according to semantic versioning whitepaper (https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf). 


was (Author: emilyj):
IIUC, the version is must have in the package-info.java. The info is used by bnd to work out the package version and extremely useful in OSGi environment. Besides, we should maintain the version correctly according to semantic versioning whitepaper (https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf). 

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  8 02:32:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 8 Dec 2016 02:32:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.34714.1481182320091@Atlassian.JIRA>


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

Martin Kouba commented on CDI-477:
----------------------------------

[~emilyj] I'm sorry but which version? I'm talking about this file: https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/package-info.java

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  8 03:21:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 8 Dec 2016 03:21:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-664) Rename
 SeContainerInitializer.addInterceptors()/addDecorators()/addAlternatives()/addAlternativeStereotypes()
 and clarify the purpose
In-Reply-To: <JIRA.12666423.1481185254000@Atlassian.JIRA>
References: <JIRA.12666423.1481185254000@Atlassian.JIRA>
	<JIRA.12666423.1481185254660@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666423.1481185254000.34853.1481185260342@Atlassian.JIRA>

Martin Kouba created CDI-664:
--------------------------------

             Summary: Rename SeContainerInitializer.addInterceptors()/addDecorators()/addAlternatives()/addAlternativeStereotypes() and clarify the purpose
                 Key: CDI-664
                 URL: https://issues.jboss.org/browse/CDI-664
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 2.0 .Final


These methods should not add any class to the set of bean classes for the synthetic bean archive. The purpose is solely to compensate the absence of the {{beans.xml}} descriptor.

The propsal is to rename:
* addInterceptors() -> enableInterceptors()
* addDecorators() -> enableDecorators()
* addAlternatives() -> selectAlternatives()
* addAlternativeStereotypes() -> selectAlternativeStereotypes()

The new names correspond to the spec wording (see for example 5.1.1. Declaring selected alternatives).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  8 03:50:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 8 Dec 2016 03:50:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-662) Fix Instance.isResolvable() text
In-Reply-To: <JIRA.12665899.1481112659000@Atlassian.JIRA>
References: <JIRA.12665899.1481112659000@Atlassian.JIRA>
	<JIRA.12665899.1481112659000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665899.1481112659000.35022.1481187000028@Atlassian.JIRA>


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

Martin Kouba updated CDI-662:
-----------------------------
    Summary: Fix Instance.isResolvable() text  (was: Fix Instance.isResolvable() text and javadoc)


> Fix Instance.isResolvable() text
> --------------------------------
>
>                 Key: CDI-662
>                 URL: https://issues.jboss.org/browse/CDI-662
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> A note that {{Instance.isResolvable()}} *IS* resolving ambiguities is missing in the spec text and javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Thu Dec  8 04:37:31 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 8 Dec 2016 10:37:31 +0100
Subject: [cdi-dev] Thread safety of SeContainer and
	SeContainerInitializer
In-Reply-To: <CY4PR04MB0486705C23DB20EF002D7B3898850@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CAHNdxunU9j9BiEO=N1UJ+dpUvrf_=9fq1VcLHnchSGfYpHLKFg@mail.gmail.com>
	<CY4PR04MB0486705C23DB20EF002D7B3898850@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <4e728b5c-2979-edd3-6fe2-d01c68fa2014@redhat.com>

I agree with John, it's not guaranteed. However, the original intention 
(based on Weld SE impl) was:

* SeContainerInitializer is not thread-safe and should not be shared 
between threads
* it should be safe to call SeContainer.close() from any thread

Martin

Dne 7.12.2016 v 22:01 John Ament napsal(a):
> I would say that this is not guaranteed.
>
>
>
> ------------------------------------------------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org
> <cdi-dev-bounces at lists.jboss.org> on behalf of Laird Nelson
> <ljnelson at gmail.com>
> *Sent:* Wednesday, December 7, 2016 3:56 PM
> *To:* cdi-dev at lists.jboss.org
> *Subject:* [cdi-dev] Thread safety of SeContainer and
> SeContainerInitializer
>
> Are SeContainer and SeContainerInitializer safe for concurrent use by
> multiple threads?  The string "concurren" shows up only four times in
> the 2.0 specification but not in this context.
>
> I'm most interested in whether it is guaranteed that one thread may call
> SeContainer::initialize and another may call SeContainer::close.
>
> I'm assuming that this is /not/ guaranteed.
>
> Best,
> Laird
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From antoine at sabot-durand.net  Thu Dec  8 05:29:11 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 08 Dec 2016 10:29:11 +0000
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
Message-ID: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>

Hi all,

As already explained in a previous mail [1],  some of us would like change
the current order of events to make the highest @Priority value first and
the lowest last.  This change would be an alinement on how @Alternative
work (highest value being the first candidate).

If you agree to the change (highest to lowest) vote +1, if you disagree -1
and don't care 0. If you want to discuss thread is always open on [1] but
time is running out.

Vote will end Monday at 12:00 pm CET.

Thanks for your participation.

Antoine

[1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161208/3c49bb79/attachment.html 

From tremes at redhat.com  Thu Dec  8 05:44:49 2016
From: tremes at redhat.com (Tomas Remes)
Date: Thu, 8 Dec 2016 05:44:49 -0500 (EST)
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
In-Reply-To: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
References: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
Message-ID: <1839721334.5186646.1481193889887.JavaMail.zimbra@redhat.com>


Well since it's not unified across alternatives, interceptors and obsevers there still will be some confusion IMO. So 0 from me. 

T.

----- Original Message -----
From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
To: "CDI Java EE Specification" <cdi-dev at lists.jboss.org>
Sent: Thursday, December 8, 2016 11:29:11 AM
Subject: [cdi-dev] [Vote] @Priority value order on ordered events

Hi all, 

As already explained in a previous mail [1], some of us would like change the current order of events to make the highest @Priority value first and the lowest last. This change would be an alinement on how @Alternative work (highest value being the first candidate). 

If you agree to the change (highest to lowest) vote +1, if you disagree -1 and don't care 0. If you want to discuss thread is always open on [1] but time is running out. 

Vote will end Monday at 12:00 pm CET. 

Thanks for your participation. 

Antoine 

[1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html 

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

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



From manovotn at redhat.com  Thu Dec  8 05:45:18 2016
From: manovotn at redhat.com (Matej Novotny)
Date: Thu, 8 Dec 2016 05:45:18 -0500 (EST)
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
In-Reply-To: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
References: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
Message-ID: <35165151.2432713.1481193918116.JavaMail.zimbra@redhat.com>

+0

Don't really care. Since it's not unified across CDI, having it one way or the other doesn't really make difference to me.

Matej

----- Original Message -----
> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
> To: "CDI Java EE Specification" <cdi-dev at lists.jboss.org>
> Sent: Thursday, December 8, 2016 11:29:11 AM
> Subject: [cdi-dev] [Vote] @Priority value order on ordered events
> 
> Hi all,
> 
> As already explained in a previous mail [1], some of us would like change the
> current order of events to make the highest @Priority value first and the
> lowest last. This change would be an alinement on how @Alternative work
> (highest value being the first candidate).
> 
> If you agree to the change (highest to lowest) vote +1, if you disagree -1
> and don't care 0. If you want to discuss thread is always open on [1] but
> time is running out.
> 
> Vote will end Monday at 12:00 pm CET.
> 
> Thanks for your participation.
> 
> Antoine
> 
> [1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.

From rmannibucau at gmail.com  Thu Dec  8 05:47:23 2016
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 8 Dec 2016 11:47:23 +0100
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
In-Reply-To: <35165151.2432713.1481193918116.JavaMail.zimbra@redhat.com>
References: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
	<35165151.2432713.1481193918116.JavaMail.zimbra@redhat.com>
Message-ID: <CACLE=7NGQBE9LSVvJY+7R+EDij6gKhvs+J6jwe+bNONOdxTOYg@mail.gmail.com>

+0 since alternative/interceptors are not aligned. On a user perspective I
find it easier is the sorting is the natural integer one but any dev knows
the ordinal ordering too so not a big deal IMHO.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-12-08 11:45 GMT+01:00 Matej Novotny <manovotn at redhat.com>:

> +0
>
> Don't really care. Since it's not unified across CDI, having it one way or
> the other doesn't really make difference to me.
>
> Matej
>
> ----- Original Message -----
> > From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
> > To: "CDI Java EE Specification" <cdi-dev at lists.jboss.org>
> > Sent: Thursday, December 8, 2016 11:29:11 AM
> > Subject: [cdi-dev] [Vote] @Priority value order on ordered events
> >
> > Hi all,
> >
> > As already explained in a previous mail [1], some of us would like
> change the
> > current order of events to make the highest @Priority value first and the
> > lowest last. This change would be an alinement on how @Alternative work
> > (highest value being the first candidate).
> >
> > If you agree to the change (highest to lowest) vote +1, if you disagree
> -1
> > and don't care 0. If you want to discuss thread is always open on [1] but
> > time is running out.
> >
> > Vote will end Monday at 12:00 pm CET.
> >
> > Thanks for your participation.
> >
> > Antoine
> >
> > [1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code
> > under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> intellectual
> > property rights inherent in such information.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161208/76068ff7/attachment.html 

From EMIJIANG at uk.ibm.com  Thu Dec  8 06:22:57 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Thu, 8 Dec 2016 11:22:57 +0000
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
In-Reply-To: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
References: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
Message-ID: <OFD456F186.94353D2E-ON80258083.003E20C0-80258083.003E8885@notes.na.collabserv.com>

-1 on the change.

I will prefer not to change and remain as lowest one first. It is natural 
and easier to be understood by end users without needing to know the 
implementation details. Since @Alternatives with the highest value is the 
overall candidate and the others are ignored, I am less keen to aline it 
up with alternatives.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Antoine Sabot-Durand <antoine at sabot-durand.net>
To:     CDI Java EE Specification <cdi-dev at lists.jboss.org>
Date:   08/12/2016 10:31
Subject:        [cdi-dev] [Vote] @Priority value order on ordered events
Sent by:        cdi-dev-bounces at lists.jboss.org



Hi all,

As already explained in a previous mail [1],  some of us would like change 
the current order of events to make the highest @Priority value first and 
the lowest last.  This change would be an alinement on how @Alternative 
work (highest value being the first candidate).

If you agree to the change (highest to lowest) vote +1, if you disagree -1 
and don't care 0. If you want to discuss thread is always open on [1] but 
time is running out.

Vote will end Monday at 12:00 pm CET.

Thanks for your participation.

Antoine

[1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the 
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
provided on this list, the provider waives all patent and other 
intellectual property rights inherent in such information.

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161208/b40b051f/attachment-0001.html 

From issues at jboss.org  Thu Dec  8 06:29:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Thu, 8 Dec 2016 06:29:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.36489.1481196540458@Atlassian.JIRA>


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

Emily Jiang commented on CDI-477:
---------------------------------

[~mkouba] sorry. I jumped to the conclusion and meant you tried to delete the version info in the package-info.java. I agree that you can go ahead to delete the other blobs of javadoc. However, we need to add the javadoc of mentioning version:
/**
 * @version xx
 */

What are the version do you say for the api packages? We need to specify them accurately as they are used by OSGi environment. I'll raise a separate issue to cover that. Please don't delete this file though.

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec  8 06:38:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 8 Dec 2016 06:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.36551.1481197080141@Atlassian.JIRA>


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

Martin Kouba commented on CDI-477:
----------------------------------

Well, this is some OSGi-specific stuff and I'm no OSGi expert. However, we have Specification-Version in MANIFEST.MF file.

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Thu Dec  8 06:51:34 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 8 Dec 2016 12:51:34 +0100
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
In-Reply-To: <35165151.2432713.1481193918116.JavaMail.zimbra@redhat.com>
References: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
	<35165151.2432713.1481193918116.JavaMail.zimbra@redhat.com>
Message-ID: <4198adb9-9068-eb4d-ad4e-eb5ea7442728@redhat.com>

+1

The sentence "Observers with smaller priority values are called first." 
sounds weird. If it were @Order annotation, the sentence would be fine 
and natural. But right now, we say that observers with highest priority 
are notified last.

By the way, interceptors are different beasts - an interceptor with the 
highest priority is "closest" to the bean method invocation, i.e. it's 
the last one which can react BEFORE the bean method is invoked and the 
first one which can react AFTER the bean invocation returns (and process 
the result).

Martin

Dne 8.12.2016 v 11:45 Matej Novotny napsal(a):
> +0
>
> Don't really care. Since it's not unified across CDI, having it one way or the other doesn't really make difference to me.
>
> Matej
>
> ----- Original Message -----
>> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
>> To: "CDI Java EE Specification" <cdi-dev at lists.jboss.org>
>> Sent: Thursday, December 8, 2016 11:29:11 AM
>> Subject: [cdi-dev] [Vote] @Priority value order on ordered events
>>
>> Hi all,
>>
>> As already explained in a previous mail [1], some of us would like change the
>> current order of events to make the highest @Priority value first and the
>> lowest last. This change would be an alinement on how @Alternative work
>> (highest value being the first candidate).
>>
>> If you agree to the change (highest to lowest) vote +1, if you disagree -1
>> and don't care 0. If you want to discuss thread is always open on [1] but
>> time is running out.
>>
>> Vote will end Monday at 12:00 pm CET.
>>
>> Thanks for your participation.
>>
>> Antoine
>>
>> [1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
>> under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other intellectual
>> property rights inherent in such information.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From struberg at yahoo.de  Thu Dec  8 08:15:39 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 8 Dec 2016 14:15:39 +0100
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
In-Reply-To: <4198adb9-9068-eb4d-ad4e-eb5ea7442728@redhat.com>
References: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
	<35165151.2432713.1481193918116.JavaMail.zimbra@redhat.com>
	<4198adb9-9068-eb4d-ad4e-eb5ea7442728@redhat.com>
Message-ID: <2F0EE14F-9D19-431E-A3D3-CABA52C64F90@yahoo.de>

-0.2.  @Priority sorting order is already confusing.
Thus one has to read about how it's meant to be anyway.

But I agree with the argument that I'd expect observers to get invoked in the order of the priority numbers. Means 1 before 2. Feels much more natural to me.

LieGrue,
strub


> Am 08.12.2016 um 12:51 schrieb Martin Kouba <mkouba at redhat.com>:
> 
> +1
> 
> The sentence "Observers with smaller priority values are called first." 
> sounds weird. If it were @Order annotation, the sentence would be fine 
> and natural. But right now, we say that observers with highest priority 
> are notified last.
> 
> By the way, interceptors are different beasts - an interceptor with the 
> highest priority is "closest" to the bean method invocation, i.e. it's 
> the last one which can react BEFORE the bean method is invoked and the 
> first one which can react AFTER the bean invocation returns (and process 
> the result).
> 
> Martin
> 
> Dne 8.12.2016 v 11:45 Matej Novotny napsal(a):
>> +0
>> 
>> Don't really care. Since it's not unified across CDI, having it one way or the other doesn't really make difference to me.
>> 
>> Matej
>> 
>> ----- Original Message -----
>>> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
>>> To: "CDI Java EE Specification" <cdi-dev at lists.jboss.org>
>>> Sent: Thursday, December 8, 2016 11:29:11 AM
>>> Subject: [cdi-dev] [Vote] @Priority value order on ordered events
>>> 
>>> Hi all,
>>> 
>>> As already explained in a previous mail [1], some of us would like change the
>>> current order of events to make the highest @Priority value first and the
>>> lowest last. This change would be an alinement on how @Alternative work
>>> (highest value being the first candidate).
>>> 
>>> If you agree to the change (highest to lowest) vote +1, if you disagree -1
>>> and don't care 0. If you want to discuss thread is always open on [1] but
>>> time is running out.
>>> 
>>> Vote will end Monday at 12:00 pm CET.
>>> 
>>> Thanks for your participation.
>>> 
>>> Antoine
>>> 
>>> [1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> Note that for all code provided on this list, the provider licenses the code
>>> under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other intellectual
>>> property rights inherent in such information.
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>> 
> 
> -- 
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



From issues at jboss.org  Fri Dec  9 05:05:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 9 Dec 2016 05:05:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.41796.1481277900166@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-477:
------------------------------------------

[~emilyj] your issue is probably related to section 10.3 of BND doc: http://bnd.bndtools.org/chapters/170-versioning.html

I suggest that we remove the outdated content in this file and that you create a specific ticket for this bnd / OSGi version tracking, since it should be tracked clearly and not mix with documentation IMO.

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  9 05:05:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 9 Dec 2016 05:05:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.41799.1481277900236@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-477:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  9 05:06:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 9 Dec 2016 05:06:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-665) Annotated configurators - provide
 an easy way to remove repeatable annotations
In-Reply-To: <JIRA.12666678.1481277941000@Atlassian.JIRA>
References: <JIRA.12666678.1481277941000@Atlassian.JIRA>
	<JIRA.12666678.1481277941615@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666678.1481277941000.41801.1481277960176@Atlassian.JIRA>

Martin Kouba created CDI-665:
--------------------------------

             Summary: Annotated configurators - provide an easy way to remove repeatable annotations
                 Key: CDI-665
                 URL: https://issues.jboss.org/browse/CDI-665
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba
             Fix For: 2.1 (Discussion)


Right now, all the configurators work with the "real" annotations, e.g. a predicate used in  {{AnnotatedTypeConfigurator.remove(Predicate<Annotation>)}} will receive the container annotation and not the repeatable annotation.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  9 05:06:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 9 Dec 2016 05:06:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-665) Annotated configurators - provide
 an easy way to remove repeatable annotations
In-Reply-To: <JIRA.12666678.1481277942000@Atlassian.JIRA>
References: <JIRA.12666678.1481277942000@Atlassian.JIRA>
	<JIRA.12666678.1481277942000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666678.1481277942000.41803.1481277960384@Atlassian.JIRA>


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

Martin Kouba updated CDI-665:
-----------------------------
    Issue Type: Feature Request  (was: Clarification)


> Annotated configurators - provide an easy way to remove repeatable annotations
> ------------------------------------------------------------------------------
>
>                 Key: CDI-665
>                 URL: https://issues.jboss.org/browse/CDI-665
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>             Fix For: 2.1 (Discussion)
>
>
> Right now, all the configurators work with the "real" annotations, e.g. a predicate used in  {{AnnotatedTypeConfigurator.remove(Predicate<Annotation>)}} will receive the container annotation and not the repeatable annotation.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  9 05:18:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 9 Dec 2016 05:18:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.41874.1481278680693@Atlassian.JIRA>


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

Antoine Sabot-Durand edited comment on CDI-477 at 12/9/16 5:17 AM:
-------------------------------------------------------------------

[~emilyj], I guess, your issue is probably related to section 10.3 of BND doc: http://bnd.bndtools.org/chapters/170-versioning.html

The doc talks of having version in package-info or manifest. We never had the version in package-info but in manifest, so removing the file won't change anything.

I suggest that we remove the file as Martin suggest it.
And if having the version in manifest and not in package-info is an issue, that issue has been here since version 1.0 and s not related to this ticket.
If so, feel free to create a specific ticket for this bnd / OSGi version tracking and detail why having version in manifest vs package-info is a issue.



was (Author: antoinesabot-durand):
[~emilyj] your issue is probably related to section 10.3 of BND doc: http://bnd.bndtools.org/chapters/170-versioning.html

I suggest that we remove the outdated content in this file and that you create a specific ticket for this bnd / OSGi version tracking, since it should be tracked clearly and not mix with documentation IMO.

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  9 05:19:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 9 Dec 2016 05:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.41877.1481278740997@Atlassian.JIRA>


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

Work on CDI-477 started by Antoine Sabot-Durand.
------------------------------------------------
> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec  9 18:07:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Fri, 9 Dec 2016 18:07:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.46064.1481324820211@Atlassian.JIRA>


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

Emily Jiang commented on CDI-477:
---------------------------------

[~antoinesabot-durand] [~mkouba] Antoine, I propose to put the export package version in package-info.java instead of manifest.mf. In this way, it is much easier to maintain each individual package version. If you add some apis in one package, you will know you need to change the package version. Each package version should be maintained individually. We should use bnd to generate the manifest.mf instead of had baking each individual package and version. I'll open up a separate jira to get this done properly.

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From john.ament at spartasystems.com  Sun Dec 11 12:40:06 2016
From: john.ament at spartasystems.com (John Ament)
Date: Sun, 11 Dec 2016 17:40:06 +0000
Subject: [cdi-dev] Clarification of BeanManager.getReference
Message-ID: <CY4PR04MB0486E26F42DADABB51573B9A98990@CY4PR04MB0486.namprd04.prod.outlook.com>

All,


A discussion popped up on a recent CXF vote.  As I understand it, per section 11.3.2 (from CDI 1.2), The Type parameter passed in to getReference is meant to be the class to proxy for the returned object, if the object requires a proxy (e.g. a normal scoped bean).  Is that accurate? Or is the underlying type the type of the returned bean, from Bean.create(CreationalContext) ?


John


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161211/1a38dc1c/attachment.html 

From issues at jboss.org  Mon Dec 12 02:55:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 12 Dec 2016 02:55:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.852.1481529300124@Atlassian.JIRA>


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

Martin Kouba commented on CDI-477:
----------------------------------

Emily, I don't think we will ever release a CDI API artifact where any package has other than the API version (e.g. 2.0). This feature might be useful in OSGi world, but I'm not sure it makes sense for a JCP standard (and Java EE API).

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Mon Dec 12 03:10:36 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 12 Dec 2016 09:10:36 +0100
Subject: [cdi-dev] Clarification of BeanManager.getReference
In-Reply-To: <CY4PR04MB0486E26F42DADABB51573B9A98990@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CY4PR04MB0486E26F42DADABB51573B9A98990@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <4cc1d8ac-7e80-2b7d-9d11-a1857d625835@redhat.com>

Hi John,

the "beanType" parameter is de facto the same as the required type of an 
injection point. So yes, the param must be one of the bean types and for 
normal scoped the returned client proxy must implement this type (+ all 
interfaces). Also note that a contextual reference (client for normal 
scoped) is not required to implement all bean types of the bean.

Martin

Dne 11.12.2016 v 18:40 John Ament napsal(a):
> All,
>
>
> A discussion popped up on a recent CXF vote.  As I understand it, per
> section 11.3.2 (from CDI 1.2), The Type parameter passed in to
> getReference is meant to be the class to proxy for the returned object,
> if the object requires a proxy (e.g. a normal scoped bean).  Is that
> accurate? Or is the underlying type the type of the returned bean, from
> Bean.create(CreationalContext) ?
>
>
> John
>
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From struberg at yahoo.de  Mon Dec 12 03:15:06 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 12 Dec 2016 09:15:06 +0100
Subject: [cdi-dev] Clarification of BeanManager.getReference
In-Reply-To: <4cc1d8ac-7e80-2b7d-9d11-a1857d625835@redhat.com>
References: <CY4PR04MB0486E26F42DADABB51573B9A98990@CY4PR04MB0486.namprd04.prod.outlook.com>
	<4cc1d8ac-7e80-2b7d-9d11-a1857d625835@redhat.com>
Message-ID: <307ED20F-4662-48BD-8E79-23FF0E2327FF@yahoo.de>

The main point (as mentioned over at CXF) is that one must not use bean.getBeanClass() as type parameter for getReference.

LieGrue,
strub


> Am 12.12.2016 um 09:10 schrieb Martin Kouba <mkouba at redhat.com>:
> 
> Hi John,
> 
> the "beanType" parameter is de facto the same as the required type of an 
> injection point. So yes, the param must be one of the bean types and for 
> normal scoped the returned client proxy must implement this type (+ all 
> interfaces). Also note that a contextual reference (client for normal 
> scoped) is not required to implement all bean types of the bean.
> 
> Martin
> 
> Dne 11.12.2016 v 18:40 John Ament napsal(a):
>> All,
>> 
>> 
>> A discussion popped up on a recent CXF vote.  As I understand it, per
>> section 11.3.2 (from CDI 1.2), The Type parameter passed in to
>> getReference is meant to be the class to proxy for the returned object,
>> if the object requires a proxy (e.g. a normal scoped bean).  Is that
>> accurate? Or is the underlying type the type of the returned bean, from
>> Bean.create(CreationalContext) ?
>> 
>> 
>> John
>> 
>> 
>> ------------------------------------------------------------------------
>> NOTICE: This e-mail message and any attachments may contain
>> confidential, proprietary, and/or privileged information which should be
>> treated accordingly. If you are not the intended recipient, please
>> notify the sender immediately by return e-mail, delete this message, and
>> destroy all physical and electronic copies. Thank you.
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>> 
> 
> -- 
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



From mkouba at redhat.com  Mon Dec 12 03:19:44 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 12 Dec 2016 09:19:44 +0100
Subject: [cdi-dev] Clarification of BeanManager.getReference
In-Reply-To: <307ED20F-4662-48BD-8E79-23FF0E2327FF@yahoo.de>
References: <CY4PR04MB0486E26F42DADABB51573B9A98990@CY4PR04MB0486.namprd04.prod.outlook.com>
	<4cc1d8ac-7e80-2b7d-9d11-a1857d625835@redhat.com>
	<307ED20F-4662-48BD-8E79-23FF0E2327FF@yahoo.de>
Message-ID: <3d2d924f-258a-5e11-3a70-3cc00cba8a30@redhat.com>

Sure thing, bean.getBeanClass() does not have to be in the set of bean 
types (producers, custom beans, bean class with @Typed, ...).

M

Dne 12.12.2016 v 09:15 Mark Struberg napsal(a):
> The main point (as mentioned over at CXF) is that one must not use bean.getBeanClass() as type parameter for getReference.
>
> LieGrue,
> strub
>
>
>> Am 12.12.2016 um 09:10 schrieb Martin Kouba <mkouba at redhat.com>:
>>
>> Hi John,
>>
>> the "beanType" parameter is de facto the same as the required type of an
>> injection point. So yes, the param must be one of the bean types and for
>> normal scoped the returned client proxy must implement this type (+ all
>> interfaces). Also note that a contextual reference (client for normal
>> scoped) is not required to implement all bean types of the bean.
>>
>> Martin
>>
>> Dne 11.12.2016 v 18:40 John Ament napsal(a):
>>> All,
>>>
>>>
>>> A discussion popped up on a recent CXF vote.  As I understand it, per
>>> section 11.3.2 (from CDI 1.2), The Type parameter passed in to
>>> getReference is meant to be the class to proxy for the returned object,
>>> if the object requires a proxy (e.g. a normal scoped bean).  Is that
>>> accurate? Or is the underlying type the type of the returned bean, from
>>> Bean.create(CreationalContext) ?
>>>
>>>
>>> John
>>>
>>>
>>> ------------------------------------------------------------------------
>>> NOTICE: This e-mail message and any attachments may contain
>>> confidential, proprietary, and/or privileged information which should be
>>> treated accordingly. If you are not the intended recipient, please
>>> notify the sender immediately by return e-mail, delete this message, and
>>> destroy all physical and electronic copies. Thank you.
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From john.ament at spartasystems.com  Mon Dec 12 06:49:35 2016
From: john.ament at spartasystems.com (John Ament)
Date: Mon, 12 Dec 2016 11:49:35 +0000
Subject: [cdi-dev] Clarification of BeanManager.getReference
In-Reply-To: <3d2d924f-258a-5e11-3a70-3cc00cba8a30@redhat.com>
References: <CY4PR04MB0486E26F42DADABB51573B9A98990@CY4PR04MB0486.namprd04.prod.outlook.com>
	<4cc1d8ac-7e80-2b7d-9d11-a1857d625835@redhat.com>
	<307ED20F-4662-48BD-8E79-23FF0E2327FF@yahoo.de>,
	<3d2d924f-258a-5e11-3a70-3cc00cba8a30@redhat.com>
Message-ID: <CY4PR04MB04868E7909901F2B34EC164A98980@CY4PR04MB0486.namprd04.prod.outlook.com>

Well it sounds almost like a user would have to find the outer most value of getTypes to figure out which is the right type.


This means that popular CDI enabled frameworks, including Camel and DeltaSpike, are potentially doing it wrong


https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/bean/BeanBuilder.java#L115

https://github.com/apache/camel/blob/master/components/camel-cdi/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L365


________________________________
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Martin Kouba <mkouba at redhat.com>
Sent: Monday, December 12, 2016 3:19 AM
To: Mark Struberg
Cc: cdi-dev
Subject: Re: [cdi-dev] Clarification of BeanManager.getReference

Sure thing, bean.getBeanClass() does not have to be in the set of bean
types (producers, custom beans, bean class with @Typed, ...).

M

Dne 12.12.2016 v 09:15 Mark Struberg napsal(a):
> The main point (as mentioned over at CXF) is that one must not use bean.getBeanClass() as type parameter for getReference.
>
> LieGrue,
> strub
>
>
>> Am 12.12.2016 um 09:10 schrieb Martin Kouba <mkouba at redhat.com>:
>>
>> Hi John,
>>
>> the "beanType" parameter is de facto the same as the required type of an
>> injection point. So yes, the param must be one of the bean types and for
>> normal scoped the returned client proxy must implement this type (+ all
>> interfaces). Also note that a contextual reference (client for normal
>> scoped) is not required to implement all bean types of the bean.
>>
>> Martin
>>
>> Dne 11.12.2016 v 18:40 John Ament napsal(a):
>>> All,
>>>
>>>
>>> A discussion popped up on a recent CXF vote.  As I understand it, per
>>> section 11.3.2 (from CDI 1.2), The Type parameter passed in to
>>> getReference is meant to be the class to proxy for the returned object,
>>> if the object requires a proxy (e.g. a normal scoped bean).  Is that
>>> accurate? Or is the underlying type the type of the returned bean, from
>>> Bean.create(CreationalContext) ?
>>>
>>>
>>> John
>>>
>>>
>>> ------------------------------------------------------------------------
>>> NOTICE: This e-mail message and any attachments may contain
>>> confidential, proprietary, and/or privileged information which should be
>>> treated accordingly. If you are not the intended recipient, please
>>> notify the sender immediately by return e-mail, delete this message, and
>>> destroy all physical and electronic copies. Thank you.
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.



>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.



>>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.



>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.



>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss Developer<https://lists.jboss.org/mailman/listinfo/cdi-dev>
lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.




Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Apache License, Version 2.0<http://www.apache.org/licenses/LICENSE-2.0.html>
www.apache.org
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.



________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161212/8bac26e3/attachment-0001.html 

From mkouba at redhat.com  Mon Dec 12 07:34:58 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 12 Dec 2016 13:34:58 +0100
Subject: [cdi-dev] Clarification of BeanManager.getReference
In-Reply-To: <CY4PR04MB04868E7909901F2B34EC164A98980@CY4PR04MB0486.namprd04.prod.outlook.com>
References: <CY4PR04MB0486E26F42DADABB51573B9A98990@CY4PR04MB0486.namprd04.prod.outlook.com>
	<4cc1d8ac-7e80-2b7d-9d11-a1857d625835@redhat.com>
	<307ED20F-4662-48BD-8E79-23FF0E2327FF@yahoo.de>
	<3d2d924f-258a-5e11-3a70-3cc00cba8a30@redhat.com>
	<CY4PR04MB04868E7909901F2B34EC164A98980@CY4PR04MB0486.namprd04.prod.outlook.com>
Message-ID: <3d2cb9d9-b882-7956-3dba-fb12975cd119@redhat.com>

Dne 12.12.2016 v 12:49 John Ament napsal(a):
> Well it sounds almost like a user would have to find the outer most
> value of getTypes to figure out which is the right type.

Well, as I said - it's the same as if you're injecting a contextual 
reference. And the user of BM.getReference() - probably extension author 
or integrator - should be aware of this. In practice, this beanType 
paramater is often ignored and the proxy implements all bean types (this 
is what Weld does in most cases).

>
>
> This means that popular CDI enabled frameworks, including Camel
> and DeltaSpike, are potentially doing it wrong
>
>
> https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/bean/BeanBuilder.java#L115
>
> https://github.com/apache/camel/blob/master/components/camel-cdi/src/main/java/org/apache/camel/cdi/CdiCamelExtension.java#L365

For a custom impl of Bean, I think it's ok to return the class of the 
extension which registered the bean.

>
>
>
> ------------------------------------------------------------------------
> *From:* cdi-dev-bounces at lists.jboss.org
> <cdi-dev-bounces at lists.jboss.org> on behalf of Martin Kouba
> <mkouba at redhat.com>
> *Sent:* Monday, December 12, 2016 3:19 AM
> *To:* Mark Struberg
> *Cc:* cdi-dev
> *Subject:* Re: [cdi-dev] Clarification of BeanManager.getReference
>
> Sure thing, bean.getBeanClass() does not have to be in the set of bean
> types (producers, custom beans, bean class with @Typed, ...).
>
> M
>
> Dne 12.12.2016 v 09:15 Mark Struberg napsal(a):
>> The main point (as mentioned over at CXF) is that one must not use bean.getBeanClass() as type parameter for getReference.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 12.12.2016 um 09:10 schrieb Martin Kouba <mkouba at redhat.com>:
>>>
>>> Hi John,
>>>
>>> the "beanType" parameter is de facto the same as the required type of an
>>> injection point. So yes, the param must be one of the bean types and for
>>> normal scoped the returned client proxy must implement this type (+ all
>>> interfaces). Also note that a contextual reference (client for normal
>>> scoped) is not required to implement all bean types of the bean.
>>>
>>> Martin
>>>
>>> Dne 11.12.2016 v 18:40 John Ament napsal(a):
>>>> All,
>>>>
>>>>
>>>> A discussion popped up on a recent CXF vote.  As I understand it, per
>>>> section 11.3.2 (from CDI 1.2), The Type parameter passed in to
>>>> getReference is meant to be the class to proxy for the returned object,
>>>> if the object requires a proxy (e.g. a normal scoped bean).  Is that
>>>> accurate? Or is the underlying type the type of the returned bean, from
>>>> Bean.create(CreationalContext) ?
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> NOTICE: This e-mail message and any attachments may contain
>>>> confidential, proprietary, and/or privileged information which should be
>>>> treated accordingly. If you are not the intended recipient, please
>>>> notify the sender immediately by return e-mail, delete this message, and
>>>> destroy all physical and electronic copies. Thank you.
>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> cdi-dev Info Page - JBoss Developer
> <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> lists.jboss.org
> List to discuss the development of CDI (the specification) To see the
> collection of prior postings to the list, visit the cdi-dev Archives.
>
>
>
>>>>
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> Apache License, Version 2.0
> <http://www.apache.org/licenses/LICENSE-2.0.html>
> www.apache.org
> Apache License Version 2.0, January 2004 http://www.apache.org/licenses/
> TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1.
> Definitions.
>
>
>
>>>>
>>>
>>> --
>>> Martin Kouba
>>> Software Engineer
>>> Red Hat, Czech Republic
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> cdi-dev Info Page - JBoss Developer
> <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> lists.jboss.org
> List to discuss the development of CDI (the specification) To see the
> collection of prior postings to the list, visit the cdi-dev Archives.
>
>
>
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> Apache License, Version 2.0
> <http://www.apache.org/licenses/LICENSE-2.0.html>
> www.apache.org
> Apache License Version 2.0, January 2004 http://www.apache.org/licenses/
> TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1.
> Definitions.
>
>
>
>>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> cdi-dev Info Page - JBoss Developer
> <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> lists.jboss.org
> List to discuss the development of CDI (the specification) To see the
> collection of prior postings to the list, visit the cdi-dev Archives.
>
>
>
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> Apache License, Version 2.0
> <http://www.apache.org/licenses/LICENSE-2.0.html>
> www.apache.org
> Apache License Version 2.0, January 2004 http://www.apache.org/licenses/
> TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1.
> Definitions.
>
>
>
> ------------------------------------------------------------------------
> NOTICE: This e-mail message and any attachments may contain
> confidential, proprietary, and/or privileged information which should be
> treated accordingly. If you are not the intended recipient, please
> notify the sender immediately by return e-mail, delete this message, and
> destroy all physical and electronic copies. Thank you.

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From antoine at sabot-durand.net  Mon Dec 12 08:04:57 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 12 Dec 2016 13:04:57 +0000
Subject: [cdi-dev] Weld 3.0 Beta1 release start Wednesday
Message-ID: <CABu-YBQYa-f-KFcGhSwqz_ozjeMQO44vJCjdv-ojQ1as81WwQA@mail.gmail.com>

Hi all,

Just to tell you that CDI 2.0 beta1 should be released on Wednesday. At
that time all PR with "riview_priority_major" should be merged, so please
continue the review work on the last 4 which are open.

Thanks,

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161212/aae92d14/attachment.html 

From antoine at sabot-durand.net  Mon Dec 12 08:15:06 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 12 Dec 2016 13:15:06 +0000
Subject: [cdi-dev] [Vote] @Priority value order on ordered events
In-Reply-To: <2F0EE14F-9D19-431E-A3D3-CABA52C64F90@yahoo.de>
References: <CABu-YBRt_z9nhpwn_Z0+YDgqHJT9mtTLEAdgd2Q4vsmZ_=DDRw@mail.gmail.com>
	<35165151.2432713.1481193918116.JavaMail.zimbra@redhat.com>
	<4198adb9-9068-eb4d-ad4e-eb5ea7442728@redhat.com>
	<2F0EE14F-9D19-431E-A3D3-CABA52C64F90@yahoo.de>
Message-ID: <CABu-YBR6HfZjjNN3PnQ8mPjw_SgRJCd_SOK-YmVbN_PkhikOYQ@mail.gmail.com>

Result of the vote results in a status quo: lowest value is first.

So to live with our conflicting way of using @Priority, we could
(unofficially) state that:

- When multiple elements should be ordered to be all invoked (events,
interceptor) in an ordered way we go from lowest to highest
- When one element should be chosen from a collection (Alternatives)
highest wins...

Antoine

On Thu, Dec 8, 2016 at 2:15 PM Mark Struberg <struberg at yahoo.de> wrote:

> -0.2.  @Priority sorting order is already confusing.
> Thus one has to read about how it's meant to be anyway.
>
> But I agree with the argument that I'd expect observers to get invoked in
> the order of the priority numbers. Means 1 before 2. Feels much more
> natural to me.
>
> LieGrue,
> strub
>
>
> > Am 08.12.2016 um 12:51 schrieb Martin Kouba <mkouba at redhat.com>:
> >
> > +1
> >
> > The sentence "Observers with smaller priority values are called first."
> > sounds weird. If it were @Order annotation, the sentence would be fine
> > and natural. But right now, we say that observers with highest priority
> > are notified last.
> >
> > By the way, interceptors are different beasts - an interceptor with the
> > highest priority is "closest" to the bean method invocation, i.e. it's
> > the last one which can react BEFORE the bean method is invoked and the
> > first one which can react AFTER the bean invocation returns (and process
> > the result).
> >
> > Martin
> >
> > Dne 8.12.2016 v 11:45 Matej Novotny napsal(a):
> >> +0
> >>
> >> Don't really care. Since it's not unified across CDI, having it one way
> or the other doesn't really make difference to me.
> >>
> >> Matej
> >>
> >> ----- Original Message -----
> >>> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
> >>> To: "CDI Java EE Specification" <cdi-dev at lists.jboss.org>
> >>> Sent: Thursday, December 8, 2016 11:29:11 AM
> >>> Subject: [cdi-dev] [Vote] @Priority value order on ordered events
> >>>
> >>> Hi all,
> >>>
> >>> As already explained in a previous mail [1], some of us would like
> change the
> >>> current order of events to make the highest @Priority value first and
> the
> >>> lowest last. This change would be an alinement on how @Alternative work
> >>> (highest value being the first candidate).
> >>>
> >>> If you agree to the change (highest to lowest) vote +1, if you
> disagree -1
> >>> and don't care 0. If you want to discuss thread is always open on [1]
> but
> >>> time is running out.
> >>>
> >>> Vote will end Monday at 12:00 pm CET.
> >>>
> >>> Thanks for your participation.
> >>>
> >>> Antoine
> >>>
> >>> [1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses
> the code
> >>> under the Apache License, Version 2
> >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> >>> provided on this list, the provider waives all patent and other
> intellectual
> >>> property rights inherent in such information.
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >>
> >
> > --
> > Martin Kouba
> > Software Engineer
> > Red Hat, Czech Republic
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161212/57eb63d7/attachment.html 

From issues at jboss.org  Mon Dec 12 18:09:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 12 Dec 2016 18:09:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-477) Update outdated package-info.java
 in javax.enterprise.inject package
In-Reply-To: <JIRA.12552189.1410790593000@Atlassian.JIRA>
References: <JIRA.12552189.1410790593000@Atlassian.JIRA>
	<JIRA.12552189.1410790593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552189.1410790593000.7304.1481584140120@Atlassian.JIRA>


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

Emily Jiang commented on CDI-477:
---------------------------------

Martin, you are right that many packages in JCP are incorrect according to OSGi version policy. It would be nice to use the OSGi versioning policy, which would be good for both JCP and OSGi. *sigh*

> Update outdated package-info.java in javax.enterprise.inject package
> --------------------------------------------------------------------
>
>                 Key: CDI-477
>                 URL: https://issues.jboss.org/browse/CDI-477
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Update or remove this javadoc.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec 12 20:34:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Mon, 12 Dec 2016 20:34:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-511) Java SE bootstrap parameter to
 disable extension loading
In-Reply-To: <JIRA.12564532.1425221984000@Atlassian.JIRA>
References: <JIRA.12564532.1425221984000@Atlassian.JIRA>
	<JIRA.12564532.1425221984000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564532.1425221984000.7400.1481592840205@Atlassian.JIRA>


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

John Ament deleted CDI-511:
---------------------------


> Java SE bootstrap parameter to disable extension loading
> --------------------------------------------------------
>
>                 Key: CDI-511
>                 URL: https://issues.jboss.org/browse/CDI-511
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: John Ament
>            Assignee: John Ament
>
> We should define a standard parameter when initializing a CDIContainer that allows a user to not load any portable extensions defined in META-INF/services/javax.enterprise.inject.spi.Extension



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec 12 20:52:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Mon, 12 Dec 2016 20:52:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-232) Relax requirements for built-in
	Instance
In-Reply-To: <JIRA.12466372.1337001823000@Atlassian.JIRA>
References: <JIRA.12466372.1337001823000@Atlassian.JIRA>
	<JIRA.12466372.1337001823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466372.1337001823000.7411.1481593920185@Atlassian.JIRA>


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

Work on CDI-232 started by John Ament.
--------------------------------------
> Relax requirements for built-in Instance
> ----------------------------------------
>
>                 Key: CDI-232
>                 URL: https://issues.jboss.org/browse/CDI-232
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.EDR
>            Reporter: Martin Kouba
>            Assignee: John Ament
>            Priority: Minor
>              Labels: F2F2016
>             Fix For: 2.0 .Final
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec 13 06:23:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 13 Dec 2016 06:23:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-666) simplify context implementation
In-Reply-To: <JIRA.12667253.1481628160000@Atlassian.JIRA>
References: <JIRA.12667253.1481628160000@Atlassian.JIRA>
	<JIRA.12667253.1481628160018@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667253.1481628160000.9800.1481628180261@Atlassian.JIRA>

Romain Manni-Bucau created CDI-666:
--------------------------------------

             Summary: simplify context implementation
                 Key: CDI-666
                 URL: https://issues.jboss.org/browse/CDI-666
             Project: CDI Specification Issues
          Issue Type: Feature Request
            Reporter: Romain Manni-Bucau


Today implementing a context leads to implementing Context or AlterableContext interface.

Then for Thread Local related scopes it leads to handle activation, deactivation (thread local set/remove) and delegation of the context to a sub context (implementing or not Context interface). Finally it requires a destroyEnd() method destroying all instances.

It also requires the instance tracking and instantiation correctly (with lock or not depending the usage).

Here is a schematic implementation (easier than previous paragraph to read ;)):

{code}
public class CommandContext implements AlterableContext {
    private final ThreadLocal<Delegate> delegate = new ThreadLocal<>();

    @Override
    public Class<? extends Annotation> getScope() {
        return CommandScoped.class;
    }

    @Override
    public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
        return delegate.get().get(component, creationalContext);
    }

    @Override
    public <T> T get(final Contextual<T> component) {
        return delegate.get().get(component);
    }

    @Override
    public boolean isActive() {
        final Delegate instance = delegate.get();
        if (instance == null) {
            delegate.remove();
            return false;
        }
        return instance.isActive();
    }

    @Override
    public void destroy(final Contextual<?> contextual) {
        delegate.get().destroy(contextual);
    }

    public Delegate newInstance() {
        return new Delegate();
    }

    public void withContext(final Delegate value, final Runnable task) {
        delegate.set(value);
        try {
            task.run();
        } finally {
            delegate.remove();
        }
    }

    public void destroy(final Delegate delegate) {
        new ArrayList<>(delegate.componentInstanceMap.keySet()).forEach(delegate::destroy);
    }

    public class Delegate implements AlterableContext {
        private final Map<Contextual<?>, BeanInstanceBag<?>> componentInstanceMap = new HashMap<>();

        private Delegate() {
            // no-op
        }

        @Override
        public Class<? extends Annotation> getScope() {
            return CommandScoped.class;
        }

        @Override
        public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
            final BeanInstanceBag value = new BeanInstanceBag<>(creationalContext);
            return (T) ofNullable(componentInstanceMap.putIfAbsent(component, value)).orElse(value).create(component);
        }

        @Override
        public <T> T get(final Contextual<T> component) {
            return (T) ofNullable(componentInstanceMap.get(component)).map(b -> b.beanInstance).orElse(null);
        }

        @Override
        public void destroy(final Contextual<?> contextual) {
            ofNullable(componentInstanceMap.remove(contextual)).filter(b -> b.beanInstance != null).ifPresent(b -> {
                final Contextual c = contextual;
                c.destroy(b.beanInstance, b.beanCreationalContext);
                b.beanCreationalContext.release();
            });
        }

        @Override
        public boolean isActive() {
            return true;
        }
    }

    @RequiredArgsConstructor
    private static class BeanInstanceBag<T> {
        private final CreationalContext<T> beanCreationalContext;
        private T beanInstance;

        public T create(final Contextual<T> contextual) {
            if (beanInstance == null) {
                beanInstance = contextual.create(beanCreationalContext);
            }
            return beanInstance;
        }
    }
}
{code}

This is a lot for finally just define (what the user wants) when a context is active.

Therefore it would be awesome is the spec would provide a context builder. Raw api proposal could be:

{code}
void addContext(@Observes final AfterBeanDiscovery abd) {
    context = abd.contextBuilder().concurrent().scope(TheScoped.class).create();
    abd.addContext(context);
}
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec 13 06:48:00 2016
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Tue, 13 Dec 2016 06:48:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-666) simplify context implementation
In-Reply-To: <JIRA.12667253.1481628160000@Atlassian.JIRA>
References: <JIRA.12667253.1481628160000@Atlassian.JIRA>
	<JIRA.12667253.1481628160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667253.1481628160000.10020.1481629680519@Atlassian.JIRA>


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

George Gastaldi commented on CDI-666:
-------------------------------------

That looks cool. It could also introduce methods (using lamdas of course) to create and destroy the context and another one to retrieve the requested object in this scope

> simplify context implementation
> -------------------------------
>
>                 Key: CDI-666
>                 URL: https://issues.jboss.org/browse/CDI-666
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> Today implementing a context leads to implementing Context or AlterableContext interface.
> Then for Thread Local related scopes it leads to handle activation, deactivation (thread local set/remove) and delegation of the context to a sub context (implementing or not Context interface). Finally it requires a destroyEnd() method destroying all instances.
> It also requires the instance tracking and instantiation correctly (with lock or not depending the usage).
> Here is a schematic implementation (easier than previous paragraph to read ;)):
> {code}
> public class CommandContext implements AlterableContext {
>     private final ThreadLocal<Delegate> delegate = new ThreadLocal<>();
>     @Override
>     public Class<? extends Annotation> getScope() {
>         return CommandScoped.class;
>     }
>     @Override
>     public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
>         return delegate.get().get(component, creationalContext);
>     }
>     @Override
>     public <T> T get(final Contextual<T> component) {
>         return delegate.get().get(component);
>     }
>     @Override
>     public boolean isActive() {
>         final Delegate instance = delegate.get();
>         if (instance == null) {
>             delegate.remove();
>             return false;
>         }
>         return instance.isActive();
>     }
>     @Override
>     public void destroy(final Contextual<?> contextual) {
>         delegate.get().destroy(contextual);
>     }
>     public Delegate newInstance() {
>         return new Delegate();
>     }
>     public void withContext(final Delegate value, final Runnable task) {
>         delegate.set(value);
>         try {
>             task.run();
>         } finally {
>             delegate.remove();
>         }
>     }
>     public void destroy(final Delegate delegate) {
>         new ArrayList<>(delegate.componentInstanceMap.keySet()).forEach(delegate::destroy);
>     }
>     public class Delegate implements AlterableContext {
>         private final Map<Contextual<?>, BeanInstanceBag<?>> componentInstanceMap = new HashMap<>();
>         private Delegate() {
>             // no-op
>         }
>         @Override
>         public Class<? extends Annotation> getScope() {
>             return CommandScoped.class;
>         }
>         @Override
>         public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
>             final BeanInstanceBag value = new BeanInstanceBag<>(creationalContext);
>             return (T) ofNullable(componentInstanceMap.putIfAbsent(component, value)).orElse(value).create(component);
>         }
>         @Override
>         public <T> T get(final Contextual<T> component) {
>             return (T) ofNullable(componentInstanceMap.get(component)).map(b -> b.beanInstance).orElse(null);
>         }
>         @Override
>         public void destroy(final Contextual<?> contextual) {
>             ofNullable(componentInstanceMap.remove(contextual)).filter(b -> b.beanInstance != null).ifPresent(b -> {
>                 final Contextual c = contextual;
>                 c.destroy(b.beanInstance, b.beanCreationalContext);
>                 b.beanCreationalContext.release();
>             });
>         }
>         @Override
>         public boolean isActive() {
>             return true;
>         }
>     }
>     @RequiredArgsConstructor
>     private static class BeanInstanceBag<T> {
>         private final CreationalContext<T> beanCreationalContext;
>         private T beanInstance;
>         public T create(final Contextual<T> contextual) {
>             if (beanInstance == null) {
>                 beanInstance = contextual.create(beanCreationalContext);
>             }
>             return beanInstance;
>         }
>     }
> }
> {code}
> This is a lot for finally just define (what the user wants) when a context is active.
> Therefore it would be awesome is the spec would provide a context builder. Raw api proposal could be:
> {code}
> void addContext(@Observes final AfterBeanDiscovery abd) {
>     context = abd.contextBuilder().concurrent().scope(TheScoped.class).create();
>     abd.addContext(context);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec 13 08:02:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 13 Dec 2016 08:02:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-663) Usage of repeatable qualifiers
 contradicts several statements in the spec
In-Reply-To: <JIRA.12666006.1481119038000@Atlassian.JIRA>
References: <JIRA.12666006.1481119038000@Atlassian.JIRA>
	<JIRA.12666006.1481119038000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666006.1481119038000.10633.1481634120366@Atlassian.JIRA>


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

Tomas Remes reopened CDI-663:
-----------------------------


We need to update this also in javadoc.

> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
>                 Key: CDI-663
>                 URL: https://issues.jboss.org/browse/CDI-663
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec 13 08:03:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 13 Dec 2016 08:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-663) Usage of repeatable qualifiers
 contradicts several statements in the spec
In-Reply-To: <JIRA.12666006.1481119038000@Atlassian.JIRA>
References: <JIRA.12666006.1481119038000@Atlassian.JIRA>
	<JIRA.12666006.1481119038000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666006.1481119038000.10636.1481634180070@Atlassian.JIRA>


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

Tomas Remes reassigned CDI-663:
-------------------------------

    Assignee: Tomas Remes


> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
>                 Key: CDI-663
>                 URL: https://issues.jboss.org/browse/CDI-663
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Tomas Remes
>            Assignee: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec 13 08:52:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 13 Dec 2016 08:52:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-663) Usage of repeatable qualifiers
 contradicts several statements in the spec
In-Reply-To: <JIRA.12666006.1481119038000@Atlassian.JIRA>
References: <JIRA.12666006.1481119038000@Atlassian.JIRA>
	<JIRA.12666006.1481119038000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666006.1481119038000.11320.1481637120269@Atlassian.JIRA>


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

John Ament commented on CDI-663:
--------------------------------

The only cases where any of these can happen is repeatable annotations, so indicating what happens in these scenarios makes sense.

> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
>                 Key: CDI-663
>                 URL: https://issues.jboss.org/browse/CDI-663
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Tomas Remes
>            Assignee: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec 13 08:53:02 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 13 Dec 2016 08:53:02 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-666) simplify context implementation
In-Reply-To: <JIRA.12667253.1481628160000@Atlassian.JIRA>
References: <JIRA.12667253.1481628160000@Atlassian.JIRA>
	<JIRA.12667253.1481628160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667253.1481628160000.11376.1481637182877@Atlassian.JIRA>


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

John Ament commented on CDI-666:
--------------------------------

+1 to doing something like this.  This is effectively every context implementation I've seen.

> simplify context implementation
> -------------------------------
>
>                 Key: CDI-666
>                 URL: https://issues.jboss.org/browse/CDI-666
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Romain Manni-Bucau
>
> Today implementing a context leads to implementing Context or AlterableContext interface.
> Then for Thread Local related scopes it leads to handle activation, deactivation (thread local set/remove) and delegation of the context to a sub context (implementing or not Context interface). Finally it requires a destroyEnd() method destroying all instances.
> It also requires the instance tracking and instantiation correctly (with lock or not depending the usage).
> Here is a schematic implementation (easier than previous paragraph to read ;)):
> {code}
> public class CommandContext implements AlterableContext {
>     private final ThreadLocal<Delegate> delegate = new ThreadLocal<>();
>     @Override
>     public Class<? extends Annotation> getScope() {
>         return CommandScoped.class;
>     }
>     @Override
>     public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
>         return delegate.get().get(component, creationalContext);
>     }
>     @Override
>     public <T> T get(final Contextual<T> component) {
>         return delegate.get().get(component);
>     }
>     @Override
>     public boolean isActive() {
>         final Delegate instance = delegate.get();
>         if (instance == null) {
>             delegate.remove();
>             return false;
>         }
>         return instance.isActive();
>     }
>     @Override
>     public void destroy(final Contextual<?> contextual) {
>         delegate.get().destroy(contextual);
>     }
>     public Delegate newInstance() {
>         return new Delegate();
>     }
>     public void withContext(final Delegate value, final Runnable task) {
>         delegate.set(value);
>         try {
>             task.run();
>         } finally {
>             delegate.remove();
>         }
>     }
>     public void destroy(final Delegate delegate) {
>         new ArrayList<>(delegate.componentInstanceMap.keySet()).forEach(delegate::destroy);
>     }
>     public class Delegate implements AlterableContext {
>         private final Map<Contextual<?>, BeanInstanceBag<?>> componentInstanceMap = new HashMap<>();
>         private Delegate() {
>             // no-op
>         }
>         @Override
>         public Class<? extends Annotation> getScope() {
>             return CommandScoped.class;
>         }
>         @Override
>         public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
>             final BeanInstanceBag value = new BeanInstanceBag<>(creationalContext);
>             return (T) ofNullable(componentInstanceMap.putIfAbsent(component, value)).orElse(value).create(component);
>         }
>         @Override
>         public <T> T get(final Contextual<T> component) {
>             return (T) ofNullable(componentInstanceMap.get(component)).map(b -> b.beanInstance).orElse(null);
>         }
>         @Override
>         public void destroy(final Contextual<?> contextual) {
>             ofNullable(componentInstanceMap.remove(contextual)).filter(b -> b.beanInstance != null).ifPresent(b -> {
>                 final Contextual c = contextual;
>                 c.destroy(b.beanInstance, b.beanCreationalContext);
>                 b.beanCreationalContext.release();
>             });
>         }
>         @Override
>         public boolean isActive() {
>             return true;
>         }
>     }
>     @RequiredArgsConstructor
>     private static class BeanInstanceBag<T> {
>         private final CreationalContext<T> beanCreationalContext;
>         private T beanInstance;
>         public T create(final Contextual<T> contextual) {
>             if (beanInstance == null) {
>                 beanInstance = contextual.create(beanCreationalContext);
>             }
>             return beanInstance;
>         }
>     }
> }
> {code}
> This is a lot for finally just define (what the user wants) when a context is active.
> Therefore it would be awesome is the spec would provide a context builder. Raw api proposal could be:
> {code}
> void addContext(@Observes final AfterBeanDiscovery abd) {
>     context = abd.contextBuilder().concurrent().scope(TheScoped.class).create();
>     abd.addContext(context);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 03:11:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 14 Dec 2016 03:11:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703041000@Atlassian.JIRA>
References: <JIRA.12667516.1481703041000@Atlassian.JIRA>
	<JIRA.12667516.1481703041856@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703041000.15452.1481703060549@Atlassian.JIRA>

Tomas Remes created CDI-667:
-------------------------------

             Summary: Session beans in trimmed bean archive
                 Key: CDI-667
                 URL: https://issues.jboss.org/browse/CDI-667
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Tomas Remes


Currently is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 03:12:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 14 Dec 2016 03:12:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.15455.1481703120206@Atlassian.JIRA>


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

Tomas Remes updated CDI-667:
----------------------------
    Description: 
Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
IMO we should state that there are discovered as beans, but it's questionable.

  was:
Currently is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
IMO we should state that there are discovered as beans, but it's questionable.



> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 03:15:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 14 Dec 2016 03:15:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.15470.1481703300229@Atlassian.JIRA>


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

Tomas Remes updated CDI-667:
----------------------------
    Fix Version/s: 2.0 .Final


> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 05:23:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 14 Dec 2016 05:23:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.16318.1481710980182@Atlassian.JIRA>


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

Emily Jiang commented on CDI-667:
---------------------------------

Session beans are and should still be considered as beans.

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 05:24:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 14 Dec 2016 05:24:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.16327.1481711040462@Atlassian.JIRA>


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

Emily Jiang edited comment on CDI-667 at 12/14/16 5:23 AM:
-----------------------------------------------------------

Session beans are and should still be considered as beans. For the trimming, it just add @Singleton and other Scope beans, which are over above the cdi beans.


was (Author: emilyj):
Session beans are and should still be considered as beans.

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 05:31:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 14 Dec 2016 05:31:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.16422.1481711461262@Atlassian.JIRA>


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

Martin Kouba commented on CDI-667:
----------------------------------

bq. Session beans are and should still be considered as beans.

I agree. We should somehow copy the text from "17.4. Default bean discovery mode for Java EE".

bq. For the trimming, it just add @Singleton and other Scope beans, which are over above the cdi beans.

I think session bean annotations are not enough. I'm not sure but I remember it was possible to use ejb descriptor instead of annotations.

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 05:42:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 14 Dec 2016 05:42:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.16586.1481712120380@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-667:
----------------------------------------

Think EJB 3.2 2.9 section already solves it:

{quote}An EJB packaged into a CDI bean archive and not annotated with javax.enterprise.inject.Vetoed
annotation, is considered a CDI-enabled bean. The CDI container performs
dependency injection on all instances of CDI-enabled session and message-driven beans{quote}

So whatever mode it is the EJB will integrate with CDI if CDI is on.

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 08:54:00 2016
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 14 Dec 2016 08:54:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.18420.1481723640408@Atlassian.JIRA>


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

Emily Jiang commented on CDI-667:
---------------------------------

Session beans - beans with session bean annotations e.g. Stateful, Singleton, Stateless or defined as session beans via ejb descriptor.

In my previous comment, I meant the javax.inject.Singleton not ejb Singleton:o. In summary, the extra beans to be discovered (with @javax.inject.Singleton or other @Scoped) are not session beans. 

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 09:58:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 14 Dec 2016 09:58:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-668) Most Example with @Priority
 provide non fully qualified contant name
In-Reply-To: <JIRA.12667640.1481727472000@Atlassian.JIRA>
References: <JIRA.12667640.1481727472000@Atlassian.JIRA>
	<JIRA.12667640.1481727472843@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667640.1481727472000.19241.1481727480216@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-668:
----------------------------------------

             Summary: Most Example with @Priority provide non fully qualified contant name
                 Key: CDI-668
                 URL: https://issues.jboss.org/browse/CDI-668
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Antoine Sabot-Durand


Example in spec show {{@Priority}} are assuming static import of {{javax.interceptor.Interceptor.Priority.APPLICATION}}

We should change them to show full qualified path or add static import to examples for readability sake.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Dec 14 09:59:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 14 Dec 2016 09:59:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-668) Most Example with @Priority
 provide non fully qualified contant name
In-Reply-To: <JIRA.12667640.1481727473000@Atlassian.JIRA>
References: <JIRA.12667640.1481727473000@Atlassian.JIRA>
	<JIRA.12667640.1481727473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667640.1481727473000.19244.1481727540797@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-668:
-------------------------------------
    Affects Version/s: 2.0.Beta1


> Most Example with @Priority provide non fully qualified contant name
> --------------------------------------------------------------------
>
>                 Key: CDI-668
>                 URL: https://issues.jboss.org/browse/CDI-668
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>
> Example in spec show {{@Priority}} are assuming static import of {{javax.interceptor.Interceptor.Priority.APPLICATION}}
> We should change them to show full qualified path or add static import to examples for readability sake.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 03:17:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 15 Dec 2016 03:17:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-669) Clarify statement wrt exception
 for Interceptionfactory.createInterceptedInstance
In-Reply-To: <JIRA.12667769.1481789782000@Atlassian.JIRA>
References: <JIRA.12667769.1481789782000@Atlassian.JIRA>
	<JIRA.12667769.1481789782109@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667769.1481789782000.22586.1481789820017@Atlassian.JIRA>

Tomas Remes created CDI-669:
-------------------------------

             Summary: Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance
                 Key: CDI-669
                 URL: https://issues.jboss.org/browse/CDI-669
             Project: CDI Specification Issues
          Issue Type: Bug
            Reporter: Tomas Remes


{{11.7. Apply interceptor programmatically}} states for method createInterceptedInstance():
| The method can be only called once, subsequent calls will throw an exception.

Which exception?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 03:19:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 15 Dec 2016 03:19:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-669) Clarify statement wrt exception
 for Interceptionfactory.createInterceptedInstance
In-Reply-To: <JIRA.12667769.1481789782000@Atlassian.JIRA>
References: <JIRA.12667769.1481789782000@Atlassian.JIRA>
	<JIRA.12667769.1481789782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667769.1481789782000.22594.1481789940128@Atlassian.JIRA>


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

Martin Kouba commented on CDI-669:
----------------------------------

Javadoc states {{IllegalStateException}}.

> Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance
> ---------------------------------------------------------------------------------
>
>                 Key: CDI-669
>                 URL: https://issues.jboss.org/browse/CDI-669
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Tomas Remes
>
> {{11.7. Apply interceptor programmatically}} states for method createInterceptedInstance():
> | The method can be only called once, subsequent calls will throw an exception.
> Which exception?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 03:20:00 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Thu, 15 Dec 2016 03:20:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-669) Clarify statement wrt exception
 for Interceptionfactory.createInterceptedInstance
In-Reply-To: <JIRA.12667769.1481789782000@Atlassian.JIRA>
References: <JIRA.12667769.1481789782000@Atlassian.JIRA>
	<JIRA.12667769.1481789782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667769.1481789782000.22597.1481790000376@Atlassian.JIRA>


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

Matej Novotny commented on CDI-669:
-----------------------------------

Nice catch, we should clarify this. I'd say IllegalStateException is a way to go.

> Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance
> ---------------------------------------------------------------------------------
>
>                 Key: CDI-669
>                 URL: https://issues.jboss.org/browse/CDI-669
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Tomas Remes
>
> {{11.7. Apply interceptor programmatically}} states for method createInterceptedInstance():
> | The method can be only called once, subsequent calls will throw an exception.
> Which exception?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 03:44:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 15 Dec 2016 03:44:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-670) Clarify
 InterceptionFactory.ignoreFinalMethods() purpose and functioning
In-Reply-To: <JIRA.12667772.1481791406000@Atlassian.JIRA>
References: <JIRA.12667772.1481791406000@Atlassian.JIRA>
	<JIRA.12667772.1481791406073@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667772.1481791406000.22814.1481791440200@Atlassian.JIRA>

Martin Kouba created CDI-670:
--------------------------------

             Summary: Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning
                 Key: CDI-670
                 URL: https://issues.jboss.org/browse/CDI-670
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba
             Fix For: 2.0 .Final


It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap):

{code:java}
 @Inject
 Foo myFoo;

 @Produces
 @RequestScoped // -> Requires a client proxy
 public Foo produce(InterceptionFactory<Foo> interceptionFactory) {
        // Suppose Foo has a final method
        return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new FinalProduct());
  }
{code}

The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method).

I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 03:46:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 15 Dec 2016 03:46:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-670) Clarify
 InterceptionFactory.ignoreFinalMethods() purpose and functioning
In-Reply-To: <JIRA.12667772.1481791406000@Atlassian.JIRA>
References: <JIRA.12667772.1481791406000@Atlassian.JIRA>
	<JIRA.12667772.1481791406000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667772.1481791406000.22829.1481791560175@Atlassian.JIRA>


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

Martin Kouba updated CDI-670:
-----------------------------
    Priority: Critical  (was: Major)


> Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning
> ------------------------------------------------------------------------
>
>                 Key: CDI-670
>                 URL: https://issues.jboss.org/browse/CDI-670
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Critical
>             Fix For: 2.0 .Final
>
>
> It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap):
> {code:java}
>  @Inject
>  Foo myFoo;
>  @Produces
>  @RequestScoped // -> Requires a client proxy
>  public Foo produce(InterceptionFactory<Foo> interceptionFactory) {
>         // Suppose Foo has a final method
>         return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new FinalProduct());
>   }
> {code}
> The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method).
> I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 03:49:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 15 Dec 2016 03:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-670) Clarify
 InterceptionFactory.ignoreFinalMethods() purpose and functioning
In-Reply-To: <JIRA.12667772.1481791406000@Atlassian.JIRA>
References: <JIRA.12667772.1481791406000@Atlassian.JIRA>
	<JIRA.12667772.1481791406000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667772.1481791406000.22837.1481791740388@Atlassian.JIRA>


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

Martin Kouba updated CDI-670:
-----------------------------
    Description: 
It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap):

{code:java}
 @Inject
 Foo myFoo;

 @Produces
 @RequestScoped // -> Requires a client proxy
 public Foo produce(InterceptionFactory<Foo> interceptionFactory) {
        // Suppose Foo has a final method
        return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new Foo());
  }
{code}

The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method).

I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*.

  was:
It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap):

{code:java}
 @Inject
 Foo myFoo;

 @Produces
 @RequestScoped // -> Requires a client proxy
 public Foo produce(InterceptionFactory<Foo> interceptionFactory) {
        // Suppose Foo has a final method
        return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new FinalProduct());
  }
{code}

The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method).

I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*.



> Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning
> ------------------------------------------------------------------------
>
>                 Key: CDI-670
>                 URL: https://issues.jboss.org/browse/CDI-670
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Priority: Critical
>             Fix For: 2.0 .Final
>
>
> It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap):
> {code:java}
>  @Inject
>  Foo myFoo;
>  @Produces
>  @RequestScoped // -> Requires a client proxy
>  public Foo produce(InterceptionFactory<Foo> interceptionFactory) {
>         // Suppose Foo has a final method
>         return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new Foo());
>   }
> {code}
> The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method).
> I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 04:43:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 15 Dec 2016 04:43:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-670) Clarify
 InterceptionFactory.ignoreFinalMethods() purpose and functioning
In-Reply-To: <JIRA.12667772.1481791406000@Atlassian.JIRA>
References: <JIRA.12667772.1481791406000@Atlassian.JIRA>
	<JIRA.12667772.1481791406000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667772.1481791406000.23128.1481794980502@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-670:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning
> ------------------------------------------------------------------------
>
>                 Key: CDI-670
>                 URL: https://issues.jboss.org/browse/CDI-670
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>            Priority: Critical
>             Fix For: 2.0 .Final
>
>
> It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap):
> {code:java}
>  @Inject
>  Foo myFoo;
>  @Produces
>  @RequestScoped // -> Requires a client proxy
>  public Foo produce(InterceptionFactory<Foo> interceptionFactory) {
>         // Suppose Foo has a final method
>         return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new Foo());
>   }
> {code}
> The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method).
> I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 05:35:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 15 Dec 2016 05:35:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089060@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.23402.1481798100520@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-671:
----------------------------------------

             Summary: SPI element related to Instance are missing info about their qualifier
                 Key: CDI-671
                 URL: https://issues.jboss.org/browse/CDI-671
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Javadoc and API
    Affects Versions: 2.0.Beta1
            Reporter: Antoine Sabot-Durand


Following elements are related to {{Instance}} interface:

* {{CDI}} class implements {{Instance}} 
* {{SeContainer}} extends {{Instance}}
* {{BeanManager.createInstance()}} returns and {{Instance}} object

If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.

We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 05:36:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 15 Dec 2016 05:36:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.23407.1481798160295@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-671:
-------------------------------------
    Fix Version/s: 2.0 .Final


> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 06:38:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 15 Dec 2016 06:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.23698.1481801880125@Atlassian.JIRA>


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

Martin Kouba commented on CDI-671:
----------------------------------

The other approach would be to simulate injection of {{Instance}} (this is what Weld does):
||Injection point||Required type||Required qualifier||{{CDI}} equivalent||
|{{@Inject Instance<Object>}}|Object|@Default|CDI.current()|
|{{@Inject @Any Instance<Object>}}|Object|@Any|CDI.current().select(Any.Literal.INSTANCE)|
|{{@Inject Instance<Foo>}}|Foo|@Default|CDI.current().select(Foo.class)|
|{{@Inject  @Any Instance<Foo>}}|Foo|@Any|CDI.current().select(Foo.class,Any.Literal.INSTANCE)|

In this case, we would have to specify that there are no required qualifiers by default and {{@Default}} is added automatically during resolution if no qualifier selected.

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 06:43:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 15 Dec 2016 06:43:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.23722.1481802180108@Atlassian.JIRA>


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

Martin Kouba commented on CDI-671:
----------------------------------

Also note that the behavior for {{javax.enterprise.inject.spi.CDI}} is undefined in CDI 1.2 and there should be no TCK test for this.

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 07:28:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Thu, 15 Dec 2016 07:28:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.24083.1481804880134@Atlassian.JIRA>


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

John Ament commented on CDI-671:
--------------------------------

Another thing not specified, which we may want to, is that you cannot {{@Inject CDI<Object>}} even though {{CDI}} inherits from {{Instance}}

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 07:34:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 15 Dec 2016 07:34:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.24131.1481805240743@Atlassian.JIRA>


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

Martin Kouba commented on CDI-671:
----------------------------------

Well, why to {{@Inject CDI<Object>}} if you could {{@Inject Instance<Object>}} and {{@Inject BeanManager}}? I don't see a benefit.

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Dec 15 10:27:00 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Thu, 15 Dec 2016 10:27:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.25107.1481815620452@Atlassian.JIRA>


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

Matej Novotny commented on CDI-671:
-----------------------------------

I think John only meant to say that the spec does not mention that you cannot {{@Inject CDI<Object>}}. Not that we should support that. I also don't see any benefit there.

as for this issue itself - not sure how OWB stands in this; they might operate differently than we do in Weld, but to me it seems reasonable to say that by doing {{CDI.current()}} you actually get the same result as if you did {{@Inject Instance<Object>}} (meaning {{@Default}}. But in case there would be too much hassle about it, I don't really see any harm in not specifying this. It has been like that since 1.2 and apparently it caused no harm.

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 01:25:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 16 Dec 2016 01:25:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.26868.1481869500943@Atlassian.JIRA>


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

Martin Kouba commented on CDI-671:
----------------------------------

bq. I think John only meant to say that the spec does not mention that you cannot @Inject CDI<Object>. 

It does not say you can ;-). I.e. there is no built-in bean with {{javax.enterprise.inject.spi.CDI}} in its set of bean types or other wording which would imply this.

bq.  I don't really see any harm in not specifying this. It has been like that since 1.2 and apparently it caused no harm.

Note that in CDI 1.2 there was only {{javax.enterprise.inject.spi.CDI}}, in 2.0 we have two more use cases ({{SeContainer}}, {{BeanManager.createInstance()}}). So the probability that a user will run into incompatibilitites is much higher.

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 02:48:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 16 Dec 2016 02:48:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of
 BeanAttributesConfigurator read methods
In-Reply-To: <JIRA.12667957.1481874471000@Atlassian.JIRA>
References: <JIRA.12667957.1481874471000@Atlassian.JIRA>
	<JIRA.12667957.1481874471277@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667957.1481874471000.26958.1481874480068@Atlassian.JIRA>

Tomas Remes created CDI-672:
-------------------------------

             Summary: Purpose of BeanAttributesConfigurator read methods 
                 Key: CDI-672
                 URL: https://issues.jboss.org/browse/CDI-672
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Tomas Remes


I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 02:49:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 16 Dec 2016 02:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of
 BeanAttributesConfigurator read methods
In-Reply-To: <JIRA.12667957.1481874471000@Atlassian.JIRA>
References: <JIRA.12667957.1481874471000@Atlassian.JIRA>
	<JIRA.12667957.1481874471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667957.1481874471000.26961.1481874540041@Atlassian.JIRA>


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

Tomas Remes updated CDI-672:
----------------------------
    Affects Version/s: 2.0.Beta1


> Purpose of BeanAttributesConfigurator read methods 
> ---------------------------------------------------
>
>                 Key: CDI-672
>                 URL: https://issues.jboss.org/browse/CDI-672
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0.Beta1
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 02:49:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 16 Dec 2016 02:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of
 BeanAttributesConfigurator read methods
In-Reply-To: <JIRA.12667957.1481874471000@Atlassian.JIRA>
References: <JIRA.12667957.1481874471000@Atlassian.JIRA>
	<JIRA.12667957.1481874471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667957.1481874471000.26962.1481874540105@Atlassian.JIRA>


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

Tomas Remes updated CDI-672:
----------------------------
    Fix Version/s: 2.0 .Final


> Purpose of BeanAttributesConfigurator read methods 
> ---------------------------------------------------
>
>                 Key: CDI-672
>                 URL: https://issues.jboss.org/browse/CDI-672
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0.Beta1
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 03:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 16 Dec 2016 03:09:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.26996.1481875740243@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-671:
------------------------------------------

[~mkouba]I find your proposal interesting. But to be sure that everyone understand, in Weld when you request a custom qualifier (i.e. {{CDI.current().select(Foo.class,MyQualifier.Literal.INSTANCE)}}), is the {{@Default}} removed or not?



> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 03:13:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 16 Dec 2016 03:13:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.27011.1481875980162@Atlassian.JIRA>


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

Martin Kouba commented on CDI-671:
----------------------------------

More or less ;-). The {{@Default}} qualifier is not added unless required qualifiers are empty. I will update the table with examples.

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 03:14:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 16 Dec 2016 03:14:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of
 BeanAttributesConfigurator read methods
In-Reply-To: <JIRA.12667957.1481874471000@Atlassian.JIRA>
References: <JIRA.12667957.1481874471000@Atlassian.JIRA>
	<JIRA.12667957.1481874471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667957.1481874471000.27014.1481876040415@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-672:
------------------------------------------

I agree, but they are useful in {{BeanConfigurator}} to be used in {{AfterBeanDiscovery}}

> Purpose of BeanAttributesConfigurator read methods 
> ---------------------------------------------------
>
>                 Key: CDI-672
>                 URL: https://issues.jboss.org/browse/CDI-672
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0.Beta1
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 03:14:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 16 Dec 2016 03:14:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-671) SPI element related to Instance
 are missing info about their qualifier
In-Reply-To: <JIRA.12667788.1481798089000@Atlassian.JIRA>
References: <JIRA.12667788.1481798089000@Atlassian.JIRA>
	<JIRA.12667788.1481798089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667788.1481798089000.27022.1481876040653@Atlassian.JIRA>


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

Martin Kouba edited comment on CDI-671 at 12/16/16 3:13 AM:
------------------------------------------------------------

The other approach would be to simulate injection of {{Instance}} (this is what Weld does):
||Injection point||Required type||Required qualifier||{{CDI}} equivalent||
|{{@Inject Instance<Object>}}|Object|@Default|CDI.current()|
|{{@Inject @Any Instance<Object>}}|Object|@Any|CDI.current().select(Any.Literal.INSTANCE)|
|{{@Inject Instance<Foo>}}|Foo|@Default|CDI.current().select(Foo.class)|
|{{@Inject  @Any Instance<Foo>}}|Foo|@Any|CDI.current().select(Foo.class,Any.Literal.INSTANCE)|
|{{@Inject  @MyQualifier Instance<Foo>}}|Foo|@MyQualifier|CDI.current().select(Foo.class,MyQualifier.Literal.INSTANCE)|

In this case, we would have to specify that there are no required qualifiers by default and {{@Default}} is added automatically during resolution if no qualifier selected.


was (Author: mkouba):
The other approach would be to simulate injection of {{Instance}} (this is what Weld does):
||Injection point||Required type||Required qualifier||{{CDI}} equivalent||
|{{@Inject Instance<Object>}}|Object|@Default|CDI.current()|
|{{@Inject @Any Instance<Object>}}|Object|@Any|CDI.current().select(Any.Literal.INSTANCE)|
|{{@Inject Instance<Foo>}}|Foo|@Default|CDI.current().select(Foo.class)|
|{{@Inject  @Any Instance<Foo>}}|Foo|@Any|CDI.current().select(Foo.class,Any.Literal.INSTANCE)|

In this case, we would have to specify that there are no required qualifiers by default and {{@Default}} is added automatically during resolution if no qualifier selected.

> SPI element related to Instance are missing info about their qualifier
> ----------------------------------------------------------------------
>
>                 Key: CDI-671
>                 URL: https://issues.jboss.org/browse/CDI-671
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Javadoc and API
>    Affects Versions: 2.0.Beta1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 .Final
>
>
> Following elements are related to {{Instance}} interface:
> * {{CDI}} class implements {{Instance}} 
> * {{SeContainer}} extends {{Instance}}
> * {{BeanManager.createInstance()}} returns and {{Instance}} object
> If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier.
> We should state in Javadoc and spec that these Instance behaves like an injected instance with  {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 03:17:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 16 Dec 2016 03:17:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of
 BeanAttributesConfigurator read methods
In-Reply-To: <JIRA.12667957.1481874471000@Atlassian.JIRA>
References: <JIRA.12667957.1481874471000@Atlassian.JIRA>
	<JIRA.12667957.1481874471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667957.1481874471000.27045.1481876220161@Atlassian.JIRA>


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

Martin Kouba commented on CDI-672:
----------------------------------

But you can't use {{BeanAttributesConfigurator}} during {{AfterBeanDiscovery}} notification, or?

> Purpose of BeanAttributesConfigurator read methods 
> ---------------------------------------------------
>
>                 Key: CDI-672
>                 URL: https://issues.jboss.org/browse/CDI-672
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0.Beta1
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 03:59:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 16 Dec 2016 03:59:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-672) Purpose of
 BeanAttributesConfigurator read methods
In-Reply-To: <JIRA.12667957.1481874471000@Atlassian.JIRA>
References: <JIRA.12667957.1481874471000@Atlassian.JIRA>
	<JIRA.12667957.1481874471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667957.1481874471000.27369.1481878741080@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-672:
------------------------------------------

Yes, we agree: remove read from BAC and keep them in BC. 

> Purpose of BeanAttributesConfigurator read methods 
> ---------------------------------------------------
>
>                 Key: CDI-672
>                 URL: https://issues.jboss.org/browse/CDI-672
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0.Beta1
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> I think we already discussed and agreed to remove these read methods from {{BeanAttributesConfigurator}}. I can't remember the arguments for this but I think I simply forgot to mention it in https://issues.jboss.org/browse/CDI-614



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 10:16:00 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Fri, 16 Dec 2016 10:16:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-673) Revisit manipulation with
 InjectionPoint(s) in ProducerConfigurator
In-Reply-To: <JIRA.12668067.1481901323000@Atlassian.JIRA>
References: <JIRA.12668067.1481901323000@Atlassian.JIRA>
	<JIRA.12668067.1481901323229@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668067.1481901323000.29127.1481901360853@Atlassian.JIRA>

Matej Novotny created CDI-673:
---------------------------------

             Summary: Revisit manipulation with InjectionPoint(s) in ProducerConfigurator
                 Key: CDI-673
                 URL: https://issues.jboss.org/browse/CDI-673
             Project: CDI Specification Issues
          Issue Type: Bug
    Affects Versions: 2.0.Beta1
            Reporter: Matej Novotny


Currently, {{ProducerConfigurator}} allows to add or replace injection points.

Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway.

Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer:

{code}
@Produces public Foo produceIt (@Default Bar) { //do stuff}
{code}

and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}.

The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following:
bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject().

However, spec says nothing about what should happen when you change implementation's set on IPs later.

Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 16 10:16:01 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Fri, 16 Dec 2016 10:16:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-673) Revisit manipulation with
 InjectionPoint(s) in ProducerConfigurator
In-Reply-To: <JIRA.12668067.1481901323000@Atlassian.JIRA>
References: <JIRA.12668067.1481901323000@Atlassian.JIRA>
	<JIRA.12668067.1481901323000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668067.1481901323000.29136.1481901361158@Atlassian.JIRA>


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

Matej Novotny updated CDI-673:
------------------------------
    Fix Version/s: 2.0 .Final


> Revisit manipulation with InjectionPoint(s) in ProducerConfigurator
> -------------------------------------------------------------------
>
>                 Key: CDI-673
>                 URL: https://issues.jboss.org/browse/CDI-673
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 2.0.Beta1
>            Reporter: Matej Novotny
>             Fix For: 2.0 .Final
>
>
> Currently, {{ProducerConfigurator}} allows to add or replace injection points.
> Firstly, {{addInjectionPoints}} - if you think about this, it does not really make sense. You already have producer method defined, it has some body and uses its parameter within that method body. So if you add any IP, the method would not make use of it anyway.
> Secondly, replacing IP with {{injectionPoints}} - now this seems useful, but in fact it won't work. As it stands, replacing them in Weld only affects validation phase, not the injection itself. This means that if you have following producer:
> {code}
> @Produces public Foo produceIt (@Default Bar) { //do stuff}
> {code}
> and meant to replace the parameter with, say, {{@MyCustom Bar}}, you would in the end still end up with {{@Default Bar}}.
> The problem here is that [spec|http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#injectiontarget] states the following:
> bq. Implementations of Producer and InjectionTarget must ensure that the set of injection points returned by getInjectionPoints() are injected by produce() or inject().
> However, spec says nothing about what should happen when you change implementation's set on IPs later.
> Note: I think we bumped into similar issue with {{BeanConfigurator}} (or some other configurator as well). I will try to dig up that discussion.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec 19 02:04:01 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 19 Dec 2016 02:04:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.31763.1482131041454@Atlassian.JIRA>


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

Tomas Remes commented on CDI-667:
---------------------------------

I would suggest to introduce new chapter 26.2 which will be named "Trimmed bean archive in Java EE" or something like that. I would state the same rules in this chapter as in {{17.4. Default bean discovery mode for Java EE}} or maybe we can only reference this chapter in the sense that same rules for EJBs apply also for trimmed bean archive. 
Hm but thinking further we should probably introduce some new wording for this. E.g not use only "discovered" but use "are not removed from the set of discovered types" instead. 

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec 19 02:13:01 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 19 Dec 2016 02:13:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.31771.1482131581180@Atlassian.JIRA>


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

Tomas Remes edited comment on CDI-667 at 12/19/16 2:12 AM:
-----------------------------------------------------------

I would suggest to introduce new chapter in 26.2 which will be named "Trimmed bean archive in Java EE" or something like that. I would state the same rules in this chapter as in {{17.4. Default bean discovery mode for Java EE}} or maybe we can only reference this chapter in the sense that same rules for EJBs apply also for trimmed bean archive. 
Hm but thinking further we should probably introduce some new wording for this. E.g not use only "discovered" but use "are not removed from the set of discovered types" instead. 


was (Author: tremes):
I would suggest to introduce new chapter 26.2 which will be named "Trimmed bean archive in Java EE" or something like that. I would state the same rules in this chapter as in {{17.4. Default bean discovery mode for Java EE}} or maybe we can only reference this chapter in the sense that same rules for EJBs apply also for trimmed bean archive. 
Hm but thinking further we should probably introduce some new wording for this. E.g not use only "discovered" but use "are not removed from the set of discovered types" instead. 

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Dec 19 02:47:01 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 19 Dec 2016 02:47:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-667) Session beans in trimmed bean
	archive
In-Reply-To: <JIRA.12667516.1481703042000@Atlassian.JIRA>
References: <JIRA.12667516.1481703042000@Atlassian.JIRA>
	<JIRA.12667516.1481703042000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667516.1481703042000.31821.1482133621362@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-667:
----------------------------------------

what about removing it from CDI spec and only referencing EJB spec for this scanning?

> Session beans in trimmed bean archive
> -------------------------------------
>
>                 Key: CDI-667
>                 URL: https://issues.jboss.org/browse/CDI-667
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>             Fix For: 2.0 .Final
>
>
> Currently it is not obvious how session beans should be treated in trimmed bean archive. In other words are they considered as beans or not? 
> IMO we should state that there are discovered as beans, but it's questionable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From john.ament at spartasystems.com  Tue Dec 20 06:42:43 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 20 Dec 2016 11:42:43 +0000
Subject: [cdi-dev] Meeting on today?
Message-ID: <MWHPR04MB04975D7D0DB56B20C228729298900@MWHPR04MB0497.namprd04.prod.outlook.com>

Hi, Just want to check if the meeting for today is still on?

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161220/97222a88/attachment.html 

From manovotn at redhat.com  Tue Dec 20 06:47:35 2016
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 20 Dec 2016 06:47:35 -0500 (EST)
Subject: [cdi-dev] Meeting on today?
In-Reply-To: <MWHPR04MB04975D7D0DB56B20C228729298900@MWHPR04MB0497.namprd04.prod.outlook.com>
References: <MWHPR04MB04975D7D0DB56B20C228729298900@MWHPR04MB0497.namprd04.prod.outlook.com>
Message-ID: <1935542078.5748429.1482234455877.JavaMail.zimbra@redhat.com>

Hi John,

I don't think there is any meeting today. Antoine is already on PTO from what I know.

Matej

----- Original Message -----
> From: "John Ament" <john.ament at spartasystems.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Tuesday, December 20, 2016 12:42:43 PM
> Subject: [cdi-dev] Meeting on today?
> 
> 
> 
> Hi, Just want to check if the meeting for today is still on?
> 
> 
> 
> 
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the sender
> immediately by return e-mail, delete this message, and destroy all physical
> and electronic copies. Thank you.
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.

From john.ament at spartasystems.com  Thu Dec 22 16:23:11 2016
From: john.ament at spartasystems.com (John Ament)
Date: Thu, 22 Dec 2016 21:23:11 +0000
Subject: [cdi-dev] Regression issue with CDI.current
Message-ID: <MWHPR04MB0497939A2093C9798C79ECF298920@MWHPR04MB0497.namprd04.prod.outlook.com>

It seems that CDI.current is failing in places where it used to succeed.


The scenarios seem to all be the same - JAR files that don't contain a beans.xml when used in SE mode can no longer invoke CDI.current.  In the past they could.


Caused by: java.lang.IllegalStateException: Unable to access CDI
at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$1(CDI.java:75)
at java.util.Optional.orElseThrow(Optional.java:290)
at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:75)
at javax.enterprise.inject.spi.CDI.current(CDI.java:51)
at ws.ament.hammock.rest.resteasy.Cdi11InjectorFactory.lookupBeanManager(Cdi11InjectorFactory.java:32)



I'll raise an issue, but not sure since this was something not specified previously.


John



________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161222/c7390568/attachment.html 

From antonin at stefanutti.fr  Fri Dec 23 05:30:39 2016
From: antonin at stefanutti.fr (Antonin Stefanutti)
Date: Fri, 23 Dec 2016 10:30:39 +0000
Subject: [cdi-dev] BeanConfigurator and ProducerConfigurator consistency
Message-ID: <C95A351F-0855-4007-BE77-118F720B9009@stefanutti.fr>

Hi all,

Is there any reason I?m missing it is possible to get an Instance in BeanConfigurator produceWith (resp. disposeWith) while it?s not in ProducerConfigurator produceWith (resp. disposeWith)?

BeanConfigurator:

<U extends T> BeanConfigurator<U> produceWith(Function<Instance<Object>, U> callback);
BeanConfigurator<T> disposeWith(BiConsumer<T, Instance<Object>> callback);

ProducerConfigurator:

<U extends T> ProducerConfigurator<T> produceWith(Function<CreationalContext<U>, U> callback);
ProducerConfigurator<T> disposeWith(Consumer<T> callback);

Besides, wouldn?t that be more concise in most use cases to provide the equivalent without the Instance parameter in BeanConfigurator (as it was before CDI 2.0.Beta1)?

Thanks,
Antonin


From issues at jboss.org  Fri Dec 23 10:52:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 23 Dec 2016 10:52:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-674) Non-deterministic behavior of
	CDI.current()
In-Reply-To: <JIRA.12668808.1482508297000@Atlassian.JIRA>
References: <JIRA.12668808.1482508297000@Atlassian.JIRA>
	<JIRA.12668808.1482508297826@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668808.1482508297000.17250.1482508320012@Atlassian.JIRA>

John Ament created CDI-674:
------------------------------

             Summary: Non-deterministic behavior of CDI.current()
                 Key: CDI-674
                 URL: https://issues.jboss.org/browse/CDI-674
             Project: CDI Specification Issues
          Issue Type: Bug
            Reporter: John Ament


The behavior of CDI.current() is not deterministic.  It uses {{findAny()}}.  It should use {{findFirst()}}

{{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 23 10:54:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 23 Dec 2016 10:54:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-675) Clarify exception thrown when CDI
 could not be looked up
In-Reply-To: <JIRA.12668809.1482508380000@Atlassian.JIRA>
References: <JIRA.12668809.1482508380000@Atlassian.JIRA>
	<JIRA.12668809.1482508380208@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668809.1482508380000.17251.1482508440162@Atlassian.JIRA>

John Ament created CDI-675:
------------------------------

             Summary: Clarify exception thrown when CDI could not be looked up
                 Key: CDI-675
                 URL: https://issues.jboss.org/browse/CDI-675
             Project: CDI Specification Issues
          Issue Type: Bug
            Reporter: John Ament


If you are unable to look up CDI the exception thrown is {{Unable to access CDI}}.  A more correct exception would be {{Unable to locate a CDIProvider for the current bean archive}} (or something along those lines)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 23 10:54:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 23 Dec 2016 10:54:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-674) Non-deterministic behavior of
	CDI.current()
In-Reply-To: <JIRA.12668808.1482508298000@Atlassian.JIRA>
References: <JIRA.12668808.1482508298000@Atlassian.JIRA>
	<JIRA.12668808.1482508298000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668808.1482508298000.17252.1482508440199@Atlassian.JIRA>


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

John Ament updated CDI-674:
---------------------------
    Affects Version/s: 2.0.Beta1


> Non-deterministic behavior of CDI.current()
> -------------------------------------------
>
>                 Key: CDI-674
>                 URL: https://issues.jboss.org/browse/CDI-674
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 2.0.Beta1
>            Reporter: John Ament
>
> The behavior of CDI.current() is not deterministic.  It uses {{findAny()}}.  It should use {{findFirst()}}
> {{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 23 10:54:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 23 Dec 2016 10:54:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-675) Clarify exception thrown when CDI
 could not be looked up
In-Reply-To: <JIRA.12668809.1482508380000@Atlassian.JIRA>
References: <JIRA.12668809.1482508380000@Atlassian.JIRA>
	<JIRA.12668809.1482508380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668809.1482508380000.17253.1482508440266@Atlassian.JIRA>


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

John Ament updated CDI-675:
---------------------------
    Affects Version/s: 2.0.Beta1


> Clarify exception thrown when CDI could not be looked up
> --------------------------------------------------------
>
>                 Key: CDI-675
>                 URL: https://issues.jboss.org/browse/CDI-675
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 2.0.Beta1
>            Reporter: John Ament
>
> If you are unable to look up CDI the exception thrown is {{Unable to access CDI}}.  A more correct exception would be {{Unable to locate a CDIProvider for the current bean archive}} (or something along those lines)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Dec 23 10:55:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 23 Dec 2016 10:55:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-674) Non-deterministic behavior of
	CDI.current()
In-Reply-To: <JIRA.12668808.1482508298000@Atlassian.JIRA>
References: <JIRA.12668808.1482508298000@Atlassian.JIRA>
	<JIRA.12668808.1482508298000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668808.1482508298000.17259.1482508500129@Atlassian.JIRA>


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

John Ament updated CDI-674:
---------------------------
    Description: 
The behavior of CDI.current() is not deterministic.  It uses {{findAny()}}.  It should use {{findFirst()}}

{{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}}

This also seems to go against what the javadocs say

bq. otherwise the first provider which can access the container is used.

  was:
The behavior of CDI.current() is not deterministic.  It uses {{findAny()}}.  It should use {{findFirst()}}

{{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}}



> Non-deterministic behavior of CDI.current()
> -------------------------------------------
>
>                 Key: CDI-674
>                 URL: https://issues.jboss.org/browse/CDI-674
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 2.0.Beta1
>            Reporter: John Ament
>
> The behavior of CDI.current() is not deterministic.  It uses {{findAny()}}.  It should use {{findFirst()}}
> {{.findAny().orElseThrow(() -> new IllegalStateException("Unable to access CDI"));}}
> This also seems to go against what the javadocs say
> bq. otherwise the first provider which can access the container is used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Dec 27 17:13:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 27 Dec 2016 17:13:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-676) Clarify missing class behavior
In-Reply-To: <JIRA.12668858.1482876773000@Atlassian.JIRA>
References: <JIRA.12668858.1482876773000@Atlassian.JIRA>
	<JIRA.12668858.1482876773963@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668858.1482876773000.17914.1482876780014@Atlassian.JIRA>

John Ament created CDI-676:
------------------------------

             Summary: Clarify missing class behavior
                 Key: CDI-676
                 URL: https://issues.jboss.org/browse/CDI-676
             Project: CDI Specification Issues
          Issue Type: Bug
            Reporter: John Ament


The spec needs to clarify missing class behavior.  Say that I have an extension that is purposely dependent on a class being present (or not present).  In Weld, that extension will be ignored due to classloader error.  OWB on the other hand throws a TypeNotPresentException.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From mkouba at redhat.com  Wed Dec 28 06:04:52 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 28 Dec 2016 12:04:52 +0100
Subject: [cdi-dev] BeanConfigurator and ProducerConfigurator consistency
In-Reply-To: <C95A351F-0855-4007-BE77-118F720B9009@stefanutti.fr>
References: <C95A351F-0855-4007-BE77-118F720B9009@stefanutti.fr>
Message-ID: <b0482f95-62a0-5684-7afb-90f0d969684c@redhat.com>

Dne 23.12.2016 v 11:30 Antonin Stefanutti napsal(a):
> Hi all,
>
> Is there any reason I?m missing it is possible to get an Instance in BeanConfigurator produceWith (resp. disposeWith) while it?s not in ProducerConfigurator produceWith (resp. disposeWith)?
>
> BeanConfigurator:
>
> <U extends T> BeanConfigurator<U> produceWith(Function<Instance<Object>, U> callback);
> BeanConfigurator<T> disposeWith(BiConsumer<T, Instance<Object>> callback);
>
> ProducerConfigurator:
>
> <U extends T> ProducerConfigurator<T> produceWith(Function<CreationalContext<U>, U> callback);
> ProducerConfigurator<T> disposeWith(Consumer<T> callback);
>
> Besides, wouldn?t that be more concise in most use cases to provide the equivalent without the Instance parameter in BeanConfigurator (as it was before CDI 2.0.Beta1)?

There is BeanConfigurator.createWith() which corresponds to 
Contextual.create().

BeanConfigurator.produceWith() is a convenient method which might be 
used to simulate producer method with parameter injection.

ProducerConfigurator.produceWith() is an equivalent of 
Producer.produce(). We might add other convenient methods in CDI 2.1.

>
> Thanks,
> Antonin
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From john.ament at spartasystems.com  Wed Dec 28 09:53:06 2016
From: john.ament at spartasystems.com (John Ament)
Date: Wed, 28 Dec 2016 14:53:06 +0000
Subject: [cdi-dev] Clarification of Any qualifier
Message-ID: <MWHPR04MB0497C490B8EE9CC58A9BDCFF98680@MWHPR04MB0497.namprd04.prod.outlook.com>

Hi,


So an issue came up with OWB and programmatic look up.


In OWB, when you use CDI.current() the instance you get back includes an any qualifier.  I do a programmatic look up of a custom bean that is registered with just a single qualifier - @Database.  OWB looks up an instance that has qualifiers Any and Database, but cannot find any because my bean doesn't declare it.


My interpretation of http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#builtin_qualifiers is that the container (OWB) should be adding @Any  to my custom bean even if I don't specify it.  Is that the proper interpretation?  Or am I required to add @Any to my bean?


John


________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161228/0884067d/attachment.html