From antoine at sabot-durand.net  Mon Aug  1 04:42:43 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 01 Aug 2016 08:42:43 +0000
Subject: [cdi-dev] F2F do we need video during the meeting?
Message-ID: <CABu-YBSUXGe3gVYJ5Kryp6OOR6SD33+Q3xJ7HPyoFyDAbxKBVA@mail.gmail.com>

Hi all,

As only few of us will attend the f2f meeting physically, we are
considering setting up resources to set up video conference during part of
the meeting.

As this adds extra work on our side, I just wanted to know if people not
attending the meeting would be interesting in this broadcast. So please let
us know by answering this mail.

Thank you,

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

From antoine at sabot-durand.net  Mon Aug  1 06:32:44 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 01 Aug 2016 10:32:44 +0000
Subject: [cdi-dev] EDR 2.0 release this week
Message-ID: <CABu-YBS=9uE_0+ZK5YjsvV3wjAr-4TnO+2G6Kj+mu3gOu4tVWQ@mail.gmail.com>

Hi all,

As planned, I'll launch the EDR 2.0 process this week.I plan to set it for
45 days since final is always plan in January.
We'll discuss latest points during tomorrow's meeting.

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

From issues at jboss.org  Tue Aug  2 06:25:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 2 Aug 2016 06:25:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend
	javax.interceptor.InvocationContext
In-Reply-To: <JIRA.12552000.1410537664000@Atlassian.JIRA>
References: <JIRA.12552000.1410537664000@Atlassian.JIRA>
	<JIRA.12552000.1410537664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552000.1410537664000.49101.1470133500396@Atlassian.JIRA>


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

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

Guys, could be nice to add this to interceptor specification, but remember that we have the {{Interceptor}} bean that can be injected in any interceptor.

As described in the [spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#interceptor] this bean gives access to the interceptors binding thru the {{getInterceptorBindings()}} method.



> Extend javax.interceptor.InvocationContext
> ------------------------------------------
>
>                 Key: CDI-468
>                 URL: https://issues.jboss.org/browse/CDI-468
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Arne Limburg
>             Fix For: 2.0 (discussion)
>
>
> Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly.
> I propose to extend the javax.interceptor.InvocationContext interface with a method
> public Annotation getInterceptorBinding() or
> public <A extends Annotation> A getInterceptorBinding(Class<A> type)
> The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug  2 07:01:02 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 2 Aug 2016 07:01:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend
	javax.interceptor.InvocationContext
In-Reply-To: <JIRA.12552000.1410537664000@Atlassian.JIRA>
References: <JIRA.12552000.1410537664000@Atlassian.JIRA>
	<JIRA.12552000.1410537664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552000.1410537664000.49305.1470135662074@Atlassian.JIRA>


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

Martin Kouba commented on CDI-468:
----------------------------------

[~antoinesabot-durand] This will not help for {{@Nonbinding}} value members (ignored by the resolution process).

> Extend javax.interceptor.InvocationContext
> ------------------------------------------
>
>                 Key: CDI-468
>                 URL: https://issues.jboss.org/browse/CDI-468
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Arne Limburg
>             Fix For: 2.0 (discussion)
>
>
> Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly.
> I propose to extend the javax.interceptor.InvocationContext interface with a method
> public Annotation getInterceptorBinding() or
> public <A extends Annotation> A getInterceptorBinding(Class<A> type)
> The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From antoine at sabot-durand.net  Tue Aug  2 09:16:11 2016
From: antoine at sabot-durand.net (antoine at sabot-durand.net)
Date: Tue, 02 Aug 2016 13:16:11 +0000
Subject: [cdi-dev] =?utf-8?q?Invitation_mise_=C3=A0_jour=3A_CDI_weekly_mee?=
	=?utf-8?q?ting_-_mar=2E_2_ao=C3=BBt_2016_18=3A00_-_19=3A00_=28CEST?=
	=?utf-8?q?=29_=28ASD_Perso=29?=
Message-ID: <001a1130d0ee45ded40539168508@google.com>

Cet ?v?nement a ?t? modifi?.

Titre : CDI weekly meeting
Weekly meeting of the CDI EG and other community members discussing CDI 2.0  
specification.
Date?: mar. 2 ao?t 2016 18:00 ? 19:00 Paris
Agenda?: ASD Perso
Participants?:
     * Antoine Sabot-Durand- organisateur
     * cdi-dev

D?tails de l'?v?nement :  
https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm9fMjAxNjA4MDJUMTYwMDAwWiBjZGktZGV2QGxpc3RzLmpib3NzLm9yZw&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0ZmUzZGIyMzhiNzEzMzhkYTU2ZjZhNmFhOWE5M2QyMDczMWM3YjQxZQ&ctz=Europe/Paris&hl=fr

Invitation de Google?Agenda?: https://www.google.com/calendar/

Vous recevez ce message ? l'adresse cdi-dev at lists.jboss.org, car vous  
participez ? cet ?v?nement.

Refusez cet ?v?nement pour ne plus recevoir de notifications le concernant.  
Vous avez ?galement la possibilit? de cr?er un compte Google ? l'adresse  
https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de  
notification pour l'int?gralit? de votre agenda.

En transf?rant cette invitation, vous risquez d'autoriser tous les  
destinataires ? modifier votre r?ponse ? l'invitation. Pour en savoir plus,  
consultez la page suivante?:  
https://support.google.com/calendar/answer/37135#forwarding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160802/da5907f3/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1646 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160802/da5907f3/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1694 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20160802/da5907f3/attachment-0001.bin 

From john.d.ament at gmail.com  Tue Aug  2 13:09:55 2016
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 02 Aug 2016 17:09:55 +0000
Subject: [cdi-dev] Updated CDI-30 PR
Message-ID: <CAOqetn8Y2E613sK8raXQM2Q2tZxowqTJRp_91rs4o4CDUbL9Ew@mail.gmail.com>

All,

I just updated the CDI-30 PR with a couple of points.

- Don't require that a new instance of ManageableContext is returned each
time.  With this the method got renamed.  I didn't have a strong reason why
it needed to and Martin seemed to have a strong opinion that it must not.

- I'd like to know what else would be pending to get this merged in.
Obviously it would be great to see this in EDR2, and the PR's been open for
a month now.

https://github.com/cdi-spec/cdi/pull/296

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160802/034a02b9/attachment.html 

From issues at jboss.org  Wed Aug  3 04:11:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 3 Aug 2016 04:11:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-589) Enhance programmatic lookup
In-Reply-To: <JIRA.12611044.1458296055000@Atlassian.JIRA>
References: <JIRA.12611044.1458296055000@Atlassian.JIRA>
	<JIRA.12611044.1458296055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611044.1458296055000.54039.1470211860514@Atlassian.JIRA>


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

Martin Kouba reassigned CDI-589:
--------------------------------

    Assignee:     (was: Martin Kouba)


> Enhance programmatic lookup
> ---------------------------
>
>                 Key: CDI-589
>                 URL: https://issues.jboss.org/browse/CDI-589
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>
> The original intent was to allow to obtain bean metadata from {{javax.enterprise.inject.Instance}} (see also CDI-515).
> The new proposal is to enhance {{Instance}} similarly as Weld API does:
> https://github.com/weld/api/blob/2.4/weld/src/main/java/org/jboss/weld/inject/WeldInstance.java



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From antoine at sabot-durand.net  Wed Aug  3 05:21:04 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 03 Aug 2016 09:21:04 +0000
Subject: [cdi-dev] [Vote] for CDI-616 resolution
Message-ID: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>

Hi all,

During yesterday(s meeting we discussed how to solve CDI-616 issue.
2 options are possible but we didn't find an agreement, so the best
solution here would be to vote.

Options are:

a) Do nothing about injection in transient fields (todays behaviour) but
add a clarification in the spec saying that using them is not supported.
b) Throw an exception at boot time if a transient field is an injection
point.

To vote, just answer to this mail with the letter of your vote. Vote will
last 72 hrs from the hour of this mail.

Thank you,

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

From EMIJIANG at uk.ibm.com  Wed Aug  3 05:38:06 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Wed, 3 Aug 2016 10:38:06 +0100
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
Message-ID: <OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>

My vote is b.

Since it is not working in the current version, no functioning 
applications should rely on it. Throwing an exception is clearer to the 
developers.

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-dev <cdi-dev at lists.jboss.org>, 
Date:   03/08/2016 10:23
Subject:        [cdi-dev] [Vote] for CDI-616 resolution
Sent by:        cdi-dev-bounces at lists.jboss.org



Hi all,

During yesterday(s meeting we discussed how to solve CDI-616 issue.
2 options are possible but we didn't find an agreement, so the best 
solution here would be to vote.

Options are:

a) Do nothing about injection in transient fields (todays behaviour) but 
add a clarification in the spec saying that using them is not supported.
b) Throw an exception at boot time if a transient field is an injection 
point.

To vote, just answer to this mail with the letter of your vote. Vote will 
last 72 hrs from the hour of this mail.

Thank you,

Antoine  _______________________________________________
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/20160803/9a73545b/attachment.html 

From rmannibucau at gmail.com  Wed Aug  3 05:42:32 2016
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Wed, 3 Aug 2016 11:42:32 +0200
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
	<OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>
Message-ID: <CACLE=7O=vtmREUtf78j_PeTDNDox_DV6dBOxko00LUQH=u=saA@mail.gmail.com>

a - usable for wizards I think (init screen uses the field then other
steps/after serialization dont touch it)


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

2016-08-03 11:38 GMT+02:00 Emily Jiang <EMIJIANG at uk.ibm.com>:

> My vote is b.
>
> Since it is not working in the current version, no functioning
> applications should rely on it. Throwing an exception is clearer to the
> developers.
>
> 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-dev <cdi-dev at lists.jboss.org>,
> Date:        03/08/2016 10:23
> Subject:        [cdi-dev] [Vote] for CDI-616 resolution
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------
>
>
>
> Hi all,
>
> During yesterday(s meeting we discussed how to solve CDI-616 issue.
> 2 options are possible but we didn't find an agreement, so the best
> solution here would be to vote.
>
> Options are:
>
> a) Do nothing about injection in transient fields (todays behaviour) but
> add a clarification in the spec saying that using them is not supported.
> b) Throw an exception at boot time if a transient field is an injection
> point.
>
> To vote, just answer to this mail with the letter of your vote. Vote will
> last 72 hrs from the hour of this mail.
>
> Thank you,
>
> Antoine  _______________________________________________
> 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
>
> _______________________________________________
> 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/20160803/e8c89ea8/attachment.html 

From manovotn at redhat.com  Wed Aug  3 06:03:45 2016
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 3 Aug 2016 06:03:45 -0400 (EDT)
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <CACLE=7O=vtmREUtf78j_PeTDNDox_DV6dBOxko00LUQH=u=saA@mail.gmail.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
	<OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>
	<CACLE=7O=vtmREUtf78j_PeTDNDox_DV6dBOxko00LUQH=u=saA@mail.gmail.com>
Message-ID: <135702490.9987284.1470218625020.JavaMail.zimbra@redhat.com>

I vote for a)

----- Original Message -----
> From: "Romain Manni-Bucau" <rmannibucau at gmail.com>
> To: "Emily Jiang" <EMIJIANG at uk.ibm.com>
> Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Wednesday, August 3, 2016 11:42:32 AM
> Subject: Re: [cdi-dev] [Vote] for CDI-616 resolution
> 
> a - usable for wizards I think (init screen uses the field then other
> steps/after serialization dont touch it)
> 
> 
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Wordpress Blog | Github | LinkedIn | Tomitriber |
> JavaEE Factory
> 
> 2016-08-03 11:38 GMT+02:00 Emily Jiang < EMIJIANG at uk.ibm.com > :
> 
> 
> My vote is b.
> 
> Since it is not working in the current version, no functioning applications
> should rely on it. Throwing an exception is clearer to the developers.
> 
> 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-dev < cdi-dev at lists.jboss.org >,
> Date: 03/08/2016 10:23
> Subject: [cdi-dev] [Vote] for CDI-616 resolution
> Sent by: cdi-dev-bounces at lists.jboss.org
> 
> 
> 
> 
> Hi all,
> 
> During yesterday(s meeting we discussed how to solve CDI-616 issue.
> 2 options are possible but we didn't find an agreement, so the best solution
> here would be to vote.
> 
> Options are:
> 
> a) Do nothing about injection in transient fields (todays behaviour) but add
> a clarification in the spec saying that using them is not supported.
> b) Throw an exception at boot time if a transient field is an injection
> point.
> 
> To vote, just answer to this mail with the letter of your vote. Vote will
> last 72 hrs from the hour of this mail.
> 
> Thank you,
> 
> Antoine _______________________________________________
> 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
> 
> _______________________________________________
> 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.

From werner.keil at gmail.com  Wed Aug  3 06:10:21 2016
From: werner.keil at gmail.com (Werner Keil)
Date: Wed, 3 Aug 2016 12:10:21 +0200
Subject: [cdi-dev] [Vote] for CDI-616 resolution
Message-ID: <CAAGawe2pPjo+mQyF9WSMintD5jczvNExyZ1kieC5df6THKBP9Q@mail.gmail.com>

I'd say b.

Enforcing the correct behavior via API sounds better than a sentence in the
spec. And makes it easier to keep implementations and applications
compatible.

Werner


On Wed, Aug 3, 2016 at 12:03 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. [Vote] for CDI-616 resolution (Antoine Sabot-Durand)
>    2. Re: [Vote] for CDI-616 resolution (Emily Jiang)
>    3. Re: [Vote] for CDI-616 resolution (Romain Manni-Bucau)
>    4. Re: [Vote] for CDI-616 resolution (Matej Novotny)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 03 Aug 2016 09:21:04 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] [Vote] for CDI-616 resolution
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> During yesterday(s meeting we discussed how to solve CDI-616 issue.
> 2 options are possible but we didn't find an agreement, so the best
> solution here would be to vote.
>
> Options are:
>
> a) Do nothing about injection in transient fields (todays behaviour) but
> add a clarification in the spec saying that using them is not supported.
> b) Throw an exception at boot time if a transient field is an injection
> point.
>
> To vote, just answer to this mail with the letter of your vote. Vote will
> last 72 hrs from the hour of this mail.
>
> Thank you,
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160803/16192536/attachment-0001.html
>
> End of cdi-dev Digest, Vol 69, Issue 3
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160803/899d4dd7/attachment.html 

From mkouba at redhat.com  Wed Aug  3 06:21:04 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 3 Aug 2016 12:21:04 +0200
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
	<OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>
Message-ID: <3c18738c-8df4-f27b-17dc-c0ee26f934be@redhat.com>

My vote is (b) - IF AND ONLY IF the definition error only applies to a 
transient field injection point which resolves to a NORMAL SCOPED BEAN. 
Because a contextual reference (client proxy) for such a bean is always 
a passivation capable dependency. So there is no need to have it transient.

Otherwise my vote is (a).

Martin


Dne 3.8.2016 v 11:38 Emily Jiang napsal(a):
> My vote is b.
>
> Since it is not working in the current version, no functioning
> applications should rely on it. Throwing an exception is clearer to the
> developers.
>
> 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-dev <cdi-dev at lists.jboss.org>,
> Date:        03/08/2016 10:23
> Subject:        [cdi-dev] [Vote] for CDI-616 resolution
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> Hi all,
>
> During yesterday(s meeting we discussed how to solve CDI-616 issue.
> 2 options are possible but we didn't find an agreement, so the best
> solution here would be to vote.
>
> Options are:
>
> a) Do nothing about injection in transient fields (todays behaviour) but
> add a clarification in the spec saying that using them is not supported.
> b) Throw an exception at boot time if a transient field is an injection
> point.
>
> To vote, just answer to this mail with the letter of your vote. Vote
> will last 72 hrs from the hour of this mail.
>
> Thank you,
>
> Antoine  _______________________________________________
> 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
>
>
> _______________________________________________
> 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 Aug  3 07:03:56 2016
From: john.ament at spartasystems.com (John Ament)
Date: Wed, 3 Aug 2016 11:03:56 +0000
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
Message-ID: <CY1PR0401MB1226A80F5164AB0B5DD7710198060@CY1PR0401MB1226.namprd04.prod.outlook.com>

My vote is (a).  The current state is that this kind of works, and we would be breaking existing apps by throwing an exception.

________________________________
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: Wednesday, August 3, 2016 5:21:04 AM
To: cdi-dev
Subject: [cdi-dev] [Vote] for CDI-616 resolution

Hi all,

During yesterday(s meeting we discussed how to solve CDI-616 issue.
2 options are possible but we didn't find an agreement, so the best solution here would be to vote.

Options are:

a) Do nothing about injection in transient fields (todays behaviour) but add a clarification in the spec saying that using them is not supported.
b) Throw an exception at boot time if a transient field is an injection point.

To vote, just answer to this mail with the letter of your vote. Vote will last 72 hrs from the hour of this mail.

Thank you,

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/20160803/78c4e92c/attachment.html 

From struberg at yahoo.de  Wed Aug  3 07:05:03 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 3 Aug 2016 11:05:03 +0000 (UTC)
Subject: [cdi-dev] Fw:  [Vote] for CDI-616 resolution
In-Reply-To: <1108990482.8364250.1470222276078.JavaMail.yahoo@mail.yahoo.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
	<1108990482.8364250.1470222276078.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <1795620293.8654671.1470222303450.JavaMail.yahoo@mail.yahoo.com>

a.)




> On Wednesday, 3 August 2016, 13:04, Mark Struberg <struberg at yahoo.de> wrote:
> > a.)
> 
> 
> 
> txs and LieGrue,
> strub
> 
> 
> On Wednesday, 3 August 2016, 11:22, Antoine Sabot-Durand 
> <antoine at sabot-durand.net> wrote:
> 
>> Hi all,
>> 
>> 
>> During yesterday(s meeting we discussed how to solve CDI-616 issue.
>> 2 options are possible but we didn't find an agreement, so the best 
> solution here would be to vote.
>> 
>> 
>> Options are:
>> 
>> 
>> a) Do nothing about injection in transient fields (todays behaviour) but add 
> a clarification in the spec saying that using them is not supported.
>> b) Throw an exception at boot time if a transient field is an injection 
> point.
>> 
>> 
>> To vote, just answer to this mail with the letter of your vote. Vote will 
> last 72 hrs from the hour of this mail.
>> 
>> 
>> Thank you,
>> 
>> 
>> Antoine  
>> _______________________________________________
>> 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 stephan at knitelius.com  Wed Aug  3 07:53:14 2016
From: stephan at knitelius.com (Stephan Knitelius)
Date: Wed, 03 Aug 2016 11:53:14 +0000
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <CY1PR0401MB1226A80F5164AB0B5DD7710198060@CY1PR0401MB1226.namprd04.prod.outlook.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
	<CY1PR0401MB1226A80F5164AB0B5DD7710198060@CY1PR0401MB1226.namprd04.prod.outlook.com>
Message-ID: <CAGMB8Y3f+ZWa390Y-ktVNvG6_h6yR1YnPt80HpDqb9=vyJ_FWg@mail.gmail.com>

(b) - apps defining transient inject points in passivatable scopes are
broken to start with.

On Wed, 3 Aug 2016 at 13:05 John Ament <john.ament at spartasystems.com> wrote:

> My vote is (a).  The current state is that this kind of works, and we
> would be breaking existing apps by throwing an exception.
> ------------------------------
> *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:* Wednesday, August 3, 2016 5:21:04 AM
> *To:* cdi-dev
>
> *Subject:* [cdi-dev] [Vote] for CDI-616 resolution
> Hi all,
>
> During yesterday(s meeting we discussed how to solve CDI-616 issue.
> 2 options are possible but we didn't find an agreement, so the best
> solution here would be to vote.
>
> Options are:
>
> a) Do nothing about injection in transient fields (todays behaviour) but
> add a clarification in the spec saying that using them is not supported.
> b) Throw an exception at boot time if a transient field is an injection
> point.
>
> To vote, just answer to this mail with the letter of your vote. Vote will
> last 72 hrs from the hour of this mail.
>
> Thank you,
>
> 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.
> _______________________________________________
> 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/20160803/8887338a/attachment-0001.html 

From EMIJIANG at uk.ibm.com  Wed Aug  3 08:55:59 2016
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Wed, 3 Aug 2016 13:55:59 +0100
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <3c18738c-8df4-f27b-17dc-c0ee26f934be@redhat.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>	<OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>
	<3c18738c-8df4-f27b-17dc-c0ee26f934be@redhat.com>
Message-ID: <OF24D5171A.171C39E4-ON80258004.0046CA72-80258004.00470C8A@notes.na.collabserv.com>

I think there are 4a and 4b
I'm happy for b to be reworded to

b) A definition error will be thrown if the injection point is transient 
and resolves to a normal scoped bean.


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:   Martin Kouba <mkouba at redhat.com>
To:     cdi-dev at lists.jboss.org, 
Date:   03/08/2016 11:22
Subject:        Re: [cdi-dev] [Vote] for CDI-616 resolution
Sent by:        cdi-dev-bounces at lists.jboss.org



My vote is (b) - IF AND ONLY IF the definition error only applies to a 
transient field injection point which resolves to a NORMAL SCOPED BEAN. 
Because a contextual reference (client proxy) for such a bean is always 
a passivation capable dependency. So there is no need to have it 
transient.

Otherwise my vote is (a).

Martin


Dne 3.8.2016 v 11:38 Emily Jiang napsal(a):
> My vote is b.
>
> Since it is not working in the current version, no functioning
> applications should rely on it. Throwing an exception is clearer to the
> developers.
>
> 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-dev <cdi-dev at lists.jboss.org>,
> Date:        03/08/2016 10:23
> Subject:        [cdi-dev] [Vote] for CDI-616 resolution
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> Hi all,
>
> During yesterday(s meeting we discussed how to solve CDI-616 issue.
> 2 options are possible but we didn't find an agreement, so the best
> solution here would be to vote.
>
> Options are:
>
> a) Do nothing about injection in transient fields (todays behaviour) but
> add a clarification in the spec saying that using them is not supported.
> b) Throw an exception at boot time if a transient field is an injection
> point.
>
> To vote, just answer to this mail with the letter of your vote. Vote
> will last 72 hrs from the hour of this mail.
>
> Thank you,
>
> Antoine  _______________________________________________
> 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
>
>
> _______________________________________________
> 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.



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/20160803/b216f654/attachment.html 

From thjanssen123 at gmail.com  Thu Aug  4 03:42:12 2016
From: thjanssen123 at gmail.com (Thorben Janssen)
Date: Thu, 4 Aug 2016 09:42:12 +0200
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <OF24D5171A.171C39E4-ON80258004.0046CA72-80258004.00470C8A@notes.na.collabserv.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
	<OF6D7A262F.ED70A786-ON80258004.0034228C-80258004.0034EEBA@notes.na.collabserv.com>
	<3c18738c-8df4-f27b-17dc-c0ee26f934be@redhat.com>
	<OF24D5171A.171C39E4-ON80258004.0046CA72-80258004.00470C8A@notes.na.collabserv.com>
Message-ID: <CAE9nDy_L6KgZXeNOQtzKvzXr6Oj2rgKPBu_5Kjj2v3cnosuQYw@mail.gmail.com>

Enforcing the right usage would be great, but it would also break existing
applications.

I, therefore, vote: (a)

Developers who introduced this to their code most likely handle the
existing behaviour in some way and I don't see a reason to break that.

--
*Thorben Janssen*

@thjanssen123 <https://twitter.com/thjanssen123>
www.thoughts-on-java.org

2016-08-03 14:55 GMT+02:00 Emily Jiang <EMIJIANG at uk.ibm.com>:

> I think there are 4a and 4b
> I'm happy for b to be reworded to
>
> b) A definition error will be thrown if the injection point is transient
> and resolves to a normal scoped bean.
>
>
> 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:        Martin Kouba <mkouba at redhat.com>
> To:        cdi-dev at lists.jboss.org,
> Date:        03/08/2016 11:22
> Subject:        Re: [cdi-dev] [Vote] for CDI-616 resolution
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------
>
>
>
> My vote is (b) - IF AND ONLY IF the definition error only applies to a
> transient field injection point which resolves to a NORMAL SCOPED BEAN.
> Because a contextual reference (client proxy) for such a bean is always
> a passivation capable dependency. So there is no need to have it transient.
>
> Otherwise my vote is (a).
>
> Martin
>
>
> Dne 3.8.2016 v 11:38 Emily Jiang napsal(a):
> > My vote is b.
> >
> > Since it is not working in the current version, no functioning
> > applications should rely on it. Throwing an exception is clearer to the
> > developers.
> >
> > 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-dev <cdi-dev at lists.jboss.org>,
> > Date:        03/08/2016 10:23
> > Subject:        [cdi-dev] [Vote] for CDI-616 resolution
> > Sent by:        cdi-dev-bounces at lists.jboss.org
> > ------------------------------------------------------------------------
> >
> >
> >
> > Hi all,
> >
> > During yesterday(s meeting we discussed how to solve CDI-616 issue.
> > 2 options are possible but we didn't find an agreement, so the best
> > solution here would be to vote.
> >
> > Options are:
> >
> > a) Do nothing about injection in transient fields (todays behaviour) but
> > add a clarification in the spec saying that using them is not supported.
> > b) Throw an exception at boot time if a transient field is an injection
> > point.
> >
> > To vote, just answer to this mail with the letter of your vote. Vote
> > will last 72 hrs from the hour of this mail.
> >
> > Thank you,
> >
> > Antoine  _______________________________________________
> > 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
> >
> >
> > _______________________________________________
> > 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.
>
>
>
> 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
>
> _______________________________________________
> 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/20160804/b302a884/attachment-0001.html 

From tremes at redhat.com  Thu Aug  4 03:58:03 2016
From: tremes at redhat.com (Tomas Remes)
Date: Thu, 4 Aug 2016 03:58:03 -0400 (EDT)
Subject: [cdi-dev] [Vote] for CDI-616 resolution
In-Reply-To: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
References: <CABu-YBSE4gAFtaa8jPLkkcOGpPci0Q3T6smneaAtCO0aC+UQcg@mail.gmail.com>
Message-ID: <1808390215.3951155.1470297483404.JavaMail.zimbra@redhat.com>


a)

----- Original Message -----
From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
To: "cdi-dev" <cdi-dev at lists.jboss.org>
Sent: Wednesday, August 3, 2016 11:21:04 AM
Subject: [cdi-dev] [Vote] for CDI-616 resolution

Hi all, 

During yesterday(s meeting we discussed how to solve CDI-616 issue. 
2 options are possible but we didn't find an agreement, so the best solution here would be to vote. 

Options are: 

a) Do nothing about injection in transient fields (todays behaviour) but add a clarification in the spec saying that using them is not supported. 
b) Throw an exception at boot time if a transient field is an injection point. 

To vote, just answer to this mail with the letter of your vote. Vote will last 72 hrs from the hour of this mail. 

Thank you, 

Antoine 

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

-- 
Tomas Remes



From builds at travis-ci.org  Sun Aug  7 15:29:48 2016
From: builds at travis-ci.org (Travis CI)
Date: Sun, 07 Aug 2016 19:29:48 +0000
Subject: [cdi-dev] Passed: cdi-spec/cdi#46 (master - b52a5f9)
In-Reply-To: <cdi-spec/cdi+150467705+passed@travis-ci.org>
Message-ID: <57a78c2b2441b_33fd8236176881194b@b72e15e7-b75d-4a5e-af3b-027a0161df69.mail>

Build Update for cdi-spec/cdi
-------------------------------------

Build: #46
Status: Passed

Duration: 6 minutes and 19 seconds
Commit: b52a5f9 (master)
Author: Antoine Sabot-Durand
Message: Prepare for development of 2.0-SNAPSHOT

View the changeset: https://github.com/cdi-spec/cdi/compare/61a3d19384c1...b52a5f97aee2

View the full build log and details: https://travis-ci.org/cdi-spec/cdi/builds/150467705

--

You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160807/30c1f58b/attachment.html 

From issues at jboss.org  Sun Aug  7 15:42:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sun, 7 Aug 2016 15:42:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an
 annotated type is.
In-Reply-To: <JIRA.12637363.1467551710000@Atlassian.JIRA>
References: <JIRA.12637363.1467551710000@Atlassian.JIRA>
	<JIRA.12637363.1467551710000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637363.1467551710000.6046.1470598920234@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-620:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: 2.0-EDR2)


> Not clear what the id for an annotated type is.
> -----------------------------------------------
>
>                 Key: CDI-620
>                 URL: https://issues.jboss.org/browse/CDI-620
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>             Fix For: 2.0 (discussion)
>
>
> The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is.
> In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Aug  7 15:42:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sun, 7 Aug 2016 15:42:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-612)
 ObserverMethodConfigurator.notifyWith() should probably accept a functional
 interface whose method throws java.lang.Exception
In-Reply-To: <JIRA.12629421.1464951703000@Atlassian.JIRA>
References: <JIRA.12629421.1464951703000@Atlassian.JIRA>
	<JIRA.12629421.1464951703000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629421.1464951703000.6048.1470598920275@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-612:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: 2.0-EDR2)


> ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-612
>                 URL: https://issues.jboss.org/browse/CDI-612
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> The regular observer methods may also throw checked exceptions (wrapped and rethrown as an (unchecked) {{ObserverException}}).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Aug  7 15:44:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sun, 7 Aug 2016 15:44:00 -0400 (EDT)
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.6056.1470599040271@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.0 (discussion)
                       (was: 2.0-EDR2)


> 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.0 (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
(v6.4.11#64026)

From john.ament at spartasystems.com  Tue Aug  9 12:12:44 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 9 Aug 2016 16:12:44 +0000
Subject: [cdi-dev] No meeting?
Message-ID: <DM2PR0401MB123243176BB654A6E370D387981C0@DM2PR0401MB1232.namprd04.prod.outlook.com>

Antoine,


Was today's meeting supposed to be canceled?


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/20160809/0405caf6/attachment-0001.html 

From issues at jboss.org  Thu Aug 11 04:31:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 11 Aug 2016 04:31:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208256@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.24018.1470904260743@Atlassian.JIRA>

Martin Kouba created CDI-624:
--------------------------------

             Summary: Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
                 Key: CDI-624
                 URL: https://issues.jboss.org/browse/CDI-624
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba


I believe we should not break the application initialization lifecycle. 

So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.

The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Aug 11 04:31:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 11 Aug 2016 04:31:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.24019.1470904260772@Atlassian.JIRA>


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

Martin Kouba updated CDI-624:
-----------------------------
    Affects Version/s: 2.0-EDR2


> Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-624
>                 URL: https://issues.jboss.org/browse/CDI-624
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>
> I believe we should not break the application initialization lifecycle. 
> So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.
> The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Aug 11 04:31:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 11 Aug 2016 04:31:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.24020.1470904260807@Atlassian.JIRA>


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

Martin Kouba updated CDI-624:
-----------------------------
    Component/s: Java SE Integration


> Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-624
>                 URL: https://issues.jboss.org/browse/CDI-624
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>
> I believe we should not break the application initialization lifecycle. 
> So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.
> The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Aug 11 04:40:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 11 Aug 2016 04:40:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.24049.1470904800148@Atlassian.JIRA>


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

Tomas Remes commented on CDI-624:
---------------------------------

Personally I would adhere more to the second solution which seems to me more explicit and let's say "traditional".

> Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-624
>                 URL: https://issues.jboss.org/browse/CDI-624
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>
> I believe we should not break the application initialization lifecycle. 
> So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.
> The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Aug 11 05:15:05 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Thu, 11 Aug 2016 05:15:05 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.24222.1470906905486@Atlassian.JIRA>


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

John Ament commented on CDI-624:
--------------------------------

These methods must have snuck in.  I was pushing hard against the idea of mixing container init and lifecycle in SE.  I would prefer the dynamic extension approach, if anything were to be followed.

> Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-624
>                 URL: https://issues.jboss.org/browse/CDI-624
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>
> I believe we should not break the application initialization lifecycle. 
> So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.
> The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From john.ament at spartasystems.com  Tue Aug 16 05:54:58 2016
From: john.ament at spartasystems.com (John Ament)
Date: Tue, 16 Aug 2016 09:54:58 +0000
Subject: [cdi-dev] Meeting on today?
Message-ID: <DM2PR0401MB1232A9FB098EDA9D139EE73B98130@DM2PR0401MB1232.namprd04.prod.outlook.com>

Hi,


Just wondering if today's CDI EG meeting is happening or not?


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/20160816/75ebd94f/attachment.html 

From manovotn at redhat.com  Tue Aug 16 06:04:38 2016
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 16 Aug 2016 06:04:38 -0400 (EDT)
Subject: [cdi-dev] Meeting on today?
In-Reply-To: <DM2PR0401MB1232A9FB098EDA9D139EE73B98130@DM2PR0401MB1232.namprd04.prod.outlook.com>
References: <DM2PR0401MB1232A9FB098EDA9D139EE73B98130@DM2PR0401MB1232.namprd04.prod.outlook.com>
Message-ID: <1493766681.1746567.1471341878001.JavaMail.zimbra@redhat.com>

Hi,

if I am not mistaken, Antoine is on a PTO till next week.
So most likely there would be no meeting.

Matej

----- Original Message -----
> From: "John Ament" <john.ament at spartasystems.com>
> To: "cdi-dev" <cdi-dev at lists.jboss.org>
> Sent: Tuesday, August 16, 2016 11:54:58 AM
> Subject: [cdi-dev] Meeting on today?
> 
> 
> 
> Hi,
> 
> 
> 
> 
> Just wondering if today's CDI EG meeting is happening or not?
> 
> 
> 
> 
> 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.

From issues at jboss.org  Wed Aug 24 04:57:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 24 Aug 2016 04:57:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with
 @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
In-Reply-To: <JIRA.12644548.1472028968000@Atlassian.JIRA>
References: <JIRA.12644548.1472028968000@Atlassian.JIRA>
	<JIRA.12644548.1472028968386@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644548.1472028968000.40976.1472029020102@Atlassian.JIRA>

Martin Kouba created CDI-625:
--------------------------------

             Summary: When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
                 Key: CDI-625
                 URL: https://issues.jboss.org/browse/CDI-625
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Events
            Reporter: Martin Kouba


The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed. 

Does it mean that:
* {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
* {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?

I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.

In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.

I believe this should be more clear.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 05:02:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 24 Aug 2016 05:02:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-601) Add container lifecycle event
 fired before container destroys all contexts
In-Reply-To: <JIRA.12626142.1463386462000@Atlassian.JIRA>
References: <JIRA.12626142.1463386462000@Atlassian.JIRA>
	<JIRA.12626142.1463386462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626142.1463386462000.41016.1472029321279@Atlassian.JIRA>


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

Martin Kouba commented on CDI-601:
----------------------------------

To sum it up, right now if we have an {{@ApplicationScoped}} bean and want to perform some cleanup before it's destroyed:
* use {{@PreDestroy}} callback - this can only be used to perfom "local" cleanup as we should NOT call other {{@ApplicationScoped}} beans from within the callback (the ordering of destruction is not defined)
*  observe {{@Destroyed(ApplicationScoped.class)}} which should be fired _"when the application is destroyed"_; but this could be tricky - see also CDI-625

I believe we should either clarify that {{@Destroyed(X.class)}} is fired before the context is destroyed (CDI-625) or introduce a new regular event {{ApplicationStopped}} when an application is stopped, before the container destroys all contexts.


> Add container lifecycle event fired before container destroys all contexts
> --------------------------------------------------------------------------
>
>                 Key: CDI-601
>                 URL: https://issues.jboss.org/browse/CDI-601
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
>
>
> The name might be something like {{BeforeContainerShutdown}}. Note that we probably cannot change the name or semantics of {{BeforeShutdown}}, which is fired after container destroys all contexts. The motivation is to allow the beans to perform some kind of cleanup before dependencies could be disposed (the ordering of destruction is not defined).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 05:28:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 24 Aug 2016 05:28:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with
 @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
In-Reply-To: <JIRA.12644548.1472028968000@Atlassian.JIRA>
References: <JIRA.12644548.1472028968000@Atlassian.JIRA>
	<JIRA.12644548.1472028968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644548.1472028968000.41227.1472030880449@Atlassian.JIRA>


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

Martin Kouba updated CDI-625:
-----------------------------
    Description: 
The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). 

Does it mean that:
* {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
* {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?

I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.

In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.

I believe this should be more clear.


  was:
The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed. 

Does it mean that:
* {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
* {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?

I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.

In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.

I believe this should be more clear.




> When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
> -------------------------------------------------------------------------------------------
>
>                 Key: CDI-625
>                 URL: https://issues.jboss.org/browse/CDI-625
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>            Reporter: Martin Kouba
>
> The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). 
> Does it mean that:
> * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?
> I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.
> In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.
> I believe this should be more clear.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 07:20:00 2016
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Wed, 24 Aug 2016 07:20:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037593000@Atlassian.JIRA>
References: <JIRA.12644583.1472037593000@Atlassian.JIRA>
	<JIRA.12644583.1472037593939@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037593000.42229.1472037600492@Atlassian.JIRA>

Mark Struberg created CDI-626:
---------------------------------

             Summary: How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
                 Key: CDI-626
                 URL: https://issues.jboss.org/browse/CDI-626
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Mark Struberg


We did hit the following situation: 
A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 

How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?

We should also define the behaviour of CDI.getBeanManager while we are at it.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 07:29:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 24 Aug 2016 07:29:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.42303.1472038140108@Atlassian.JIRA>


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

Martin Kouba commented on CDI-626:
----------------------------------

I believe that both {{CDIProvider.getCDI()}} and {{CDI.getBeanManager()}} should throw an {{IllegalStateException}}. But then a user would have no easy way to determine whether a CDI container is running or not (except for catching the exception).

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 07:33:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 24 Aug 2016 07:33:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.42356.1472038380946@Atlassian.JIRA>


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

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

I agree getBeanManager() should throw an exception but also means CDIProvider.getCDI() doesn't otherwise we can't call it. Moreover CDIProvider is a plain SPI today and I think it is good to keep it simple so I would put the behavior in the impl and therefore CDI only. Nice thing doing that is the API stay simple and deployment doesn't affect runtime behavior (OSGi/JBoss module or graph classloading, hierarchical classloading, flat classloading).

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 07:45:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 24 Aug 2016 07:45:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.42778.1472039101128@Atlassian.JIRA>


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

Martin Kouba commented on CDI-626:
----------------------------------

Hm, I see. But if we do then a {{CDIProvider}} would have to return some "uninitialized" {{CDI}} instance anyway. So I don't see a difference here. Either CDIProvider impl or CDI impl would have to handle this. Actually, the returned CDI instance would have to handle this for all methods inherited from {{javax.enterprise.inject.Instance}}. From impl point of view, CDIProvider modification will be one method, CDI modification many methods.

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 07:54:00 2016
From: issues at jboss.org (Arjan t (JIRA))
Date: Wed, 24 Aug 2016 07:54:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.43144.1472039640340@Atlassian.JIRA>


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

Arjan t commented on CDI-626:
-----------------------------

Additionally, what about the bean manager obtained from JNDI? In Mojarra we use that as well (it's on my TODO list to make sure we use the same method everywhere). I haven't tried it yet, but in that case would the bean manager simply not be present in JNDI, or would a non-functional one be returned, or... ?

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 08:03:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 24 Aug 2016 08:03:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.43206.1472040180265@Atlassian.JIRA>


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

Martin Kouba commented on CDI-626:
----------------------------------

[~arjant] Good point. I would guess that you mostly get some {{javax.naming.NamingException}} today.

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 08:35:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 24 Aug 2016 08:35:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.43409.1472042100774@Atlassian.JIRA>


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

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

Ok so rephrased it means: when should the resolution of the CDI context occurs: in the provider or in the CDI instance. For me the provider is a hook to let the impl be plugged so I'm tempted to say we can let getCdi() be passthrough and fail on getBeanManager() only. What you can "uninitialized" could actually be "initialized" as JNDI context is active but a resource can not be bound behind a name.

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 08:40:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 24 Aug 2016 08:40:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.43502.1472042400440@Atlassian.JIRA>


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

Romain Manni-Bucau edited comment on CDI-626 at 8/24/16 8:39 AM:
-----------------------------------------------------------------

Ok so rephrased it means: when should the resolution of the CDI context occurs: in the provider or in the CDI instance. For me the provider is a hook to let the impl be plugged so I'm tempted to say we can let getCdi() be passthrough and fail on getBeanManager() only. What you called "uninitialized" could actually be "initialized" as JNDI context is active but a resource can not be bound behind a name.


was (Author: rmannibucau):
Ok so rephrased it means: when should the resolution of the CDI context occurs: in the provider or in the CDI instance. For me the provider is a hook to let the impl be plugged so I'm tempted to say we can let getCdi() be passthrough and fail on getBeanManager() only. What you can "uninitialized" could actually be "initialized" as JNDI context is active but a resource can not be bound behind a name.

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 08:45:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 24 Aug 2016 08:45:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.43533.1472042701014@Atlassian.JIRA>


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

Martin Kouba commented on CDI-626:
----------------------------------

bq. and fail on getBeanManager() only
..and also {{CDI.select()}}, {{CDI.destroy()}}, etc.

For me the provider is responsible to lookup a "valid" container instance and it's useless to return an instance which would throw ISE on each invocation. But it's probably just a matter of taste ;-). The EG should decide...


> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 24 08:53:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 24 Aug 2016 08:53:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.43591.1472043180707@Atlassian.JIRA>


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

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

well a bit more than taste cause it implies how an application can test if CDI is there: is getCdi() enough or should it tries to call one CDI method too? Also not sure what "container" means in your comment, I see CDI as the CDI container handle so anything before is not really CDI (= the CDIProvider is a bridge to CDI but doesn't require CDI). That said agree we just need to make it clear. One point can maybe be to check the api jars out there and see if changing the impl isn't easier since people will maybe not upgrade their API :s.

Also it viciously brings the question of the contextuality of CDIProvider which is maybe not something we want to "spec" yet (ie is the provider bound to an impl and one context once the lookup is done or is CDI only contextual?).

> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:40:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:40:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on
 InjectionPoint,
 and what happens when an InjectionPoint is injected into a Decorator
In-Reply-To: <JIRA.12428902.1295985650000@Atlassian.JIRA>
References: <JIRA.12428902.1295985650000@Atlassian.JIRA>
	<JIRA.12428902.1295985650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428902.1295985650000.55112.1472200800249@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-78:
------------------------------------
    Labels: F2F2016  (was: )


> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-78
>                 URL: https://issues.jboss.org/browse/CDI-78
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>              Labels: F2F2016
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:44:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:44:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-129) Clarify behaviour of
 @ApplicationScoped in EARs
In-Reply-To: <JIRA.12437380.1305278142000@Atlassian.JIRA>
References: <JIRA.12437380.1305278142000@Atlassian.JIRA>
	<JIRA.12437380.1305278142000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437380.1305278142000.55133.1472201041325@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-129:
-------------------------------------
    Labels: F2F2016 application-scoped visibility  (was: application-scoped visibility)


> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
>                 Key: CDI-129
>                 URL: https://issues.jboss.org/browse/CDI-129
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.0
>            Reporter: Mark Struberg
>            Assignee: Pete Muir
>              Labels: F2F2016, application-scoped, visibility
>             Fix For: 2.0 (discussion)
>
>
> Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> We could (ab-)use @Singleton for that, but this is currently not well defined at all.
> Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:46:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:46:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-142) Clarify behaviour of specializing
 beans across bean archive boundaries
In-Reply-To: <JIRA.12441144.1309906595000@Atlassian.JIRA>
References: <JIRA.12441144.1309906595000@Atlassian.JIRA>
	<JIRA.12441144.1309906595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441144.1309906595000.55139.1472201160451@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-142:
-------------------------------------
    Labels: F2F2016  (was: )


> Clarify behaviour of specializing beans across bean archive boundaries
> ----------------------------------------------------------------------
>
>                 Key: CDI-142
>                 URL: https://issues.jboss.org/browse/CDI-142
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Resolution
>    Affects Versions: 1.0
>            Reporter: Stuart Douglas
>              Labels: F2F2016
>             Fix For: TBD
>
>
> For instance, if a bean in a war specializes a bean in an ejb jar does the bean in the war become visible to other bean archives that would not normally be able to see it?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:49:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:49:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes
 session bean is undefined
In-Reply-To: <JIRA.12462205.1332363812000@Atlassian.JIRA>
References: <JIRA.12462205.1332363812000@Atlassian.JIRA>
	<JIRA.12462205.1332363812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.55150.1472201340883@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-220:
-------------------------------------
    Labels: CDI_spec_chge F2F2016  (was: CDI_spec_chge)


> behaviour of CDI bean @Specializes session bean is undefined
> ------------------------------------------------------------
>
>                 Key: CDI-220
>                 URL: https://issues.jboss.org/browse/CDI-220
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.0, 1.1.EDR
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, F2F2016
>             Fix For: 2.0 (discussion)
>
>
> The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g.
> @Stateless
> public class Horse {..}
> @ApplicationScoped @Specializes
> public class Trakehner extends Horse {..}
> Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error.
> Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:56:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:56:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes
 session bean is undefined
In-Reply-To: <JIRA.12462205.1332363812000@Atlassian.JIRA>
References: <JIRA.12462205.1332363812000@Atlassian.JIRA>
	<JIRA.12462205.1332363812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.55228.1472201760195@Atlassian.JIRA>


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

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

Should be Forbidden IMO. Only a Session Bean can specialized a Session Bean.

> behaviour of CDI bean @Specializes session bean is undefined
> ------------------------------------------------------------
>
>                 Key: CDI-220
>                 URL: https://issues.jboss.org/browse/CDI-220
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.0, 1.1.EDR
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, F2F2016
>             Fix For: 2.0 (discussion)
>
>
> The current spec doesn't define what should happen if a CDI bean @Specializes a session bean, e.g.
> @Stateless
> public class Horse {..}
> @ApplicationScoped @Specializes
> public class Trakehner extends Horse {..}
> Section 3.2.4 explicitely forbids the other way around. I think we should also treat the above case as error.
> Otherwise we would end up getting different results whether we use @Inject or @EJB to inject a Horse.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:57:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:57:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on
 InjectionPoint,
 and what happens when an InjectionPoint is injected into a Decorator
In-Reply-To: <JIRA.12428902.1295985650000@Atlassian.JIRA>
References: <JIRA.12428902.1295985650000@Atlassian.JIRA>
	<JIRA.12428902.1295985650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12428902.1295985650000.55234.1472201820590@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-78:
------------------------------------
    Fix Version/s: 2.0 (discussion)


> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-78
>                 URL: https://issues.jboss.org/browse/CDI-78
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Decorators
>    Affects Versions: 1.0
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:57:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:57:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-142) Clarify behaviour of specializing
 beans across bean archive boundaries
In-Reply-To: <JIRA.12441144.1309906595000@Atlassian.JIRA>
References: <JIRA.12441144.1309906595000@Atlassian.JIRA>
	<JIRA.12441144.1309906595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441144.1309906595000.55239.1472201820866@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-142:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Clarify behaviour of specializing beans across bean archive boundaries
> ----------------------------------------------------------------------
>
>                 Key: CDI-142
>                 URL: https://issues.jboss.org/browse/CDI-142
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Resolution
>    Affects Versions: 1.0
>            Reporter: Stuart Douglas
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> For instance, if a bean in a war specializes a bean in an ejb jar does the bean in the war become visible to other bean archives that would not normally be able to see it?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Aug 26 04:58:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 26 Aug 2016 04:58:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-226) Clarify the @Singleton behaviour
In-Reply-To: <JIRA.12465573.1336029589000@Atlassian.JIRA>
References: <JIRA.12465573.1336029589000@Atlassian.JIRA>
	<JIRA.12465573.1336029589000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465573.1336029589000.55262.1472201881418@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-226:
-------------------------------------
    Labels: F2F2016 application-scoped singleton  (was: application-scoped singleton)


> Clarify the @Singleton behaviour
> --------------------------------
>
>                 Key: CDI-226
>                 URL: https://issues.jboss.org/browse/CDI-226
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.EDR
>            Reporter: Daniel Sachse
>              Labels: F2F2016, application-scoped, singleton
>             Fix For: 2.0 (discussion)
>
>
> The specification should make a more clear statement about the Scope and Lifecycle of the @Singleton annotation.
> ATM it is e.g. totally unclear, in which environment a Singleton is guaranteed to be a Singleton(JVM, EAR, WAR,... ).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 06:02:07 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 06:02:07 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-375) Fix java.net webpage
In-Reply-To: <JIRA.12493988.1370910932000@Atlassian.JIRA>
References: <JIRA.12493988.1370910932000@Atlassian.JIRA>
	<JIRA.12493988.1370910932000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493988.1370910932000.61530.1472464927105@Atlassian.JIRA>


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

Antoine Sabot-Durand closed CDI-375.
------------------------------------
    Resolution: Out of Date


Java.net is closing in the coming months

> Fix java.net webpage
> --------------------
>
>                 Key: CDI-375
>                 URL: https://issues.jboss.org/browse/CDI-375
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Bruno Borges
>
> Can someone please fix the Java.net landing page to point to correct links?
> https://java.net/projects/cdi-spec/pages/Home
> Thanks



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 06:03:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 06:03:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-403) why decorator requires interface
In-Reply-To: <JIRA.12501342.1379980654000@Atlassian.JIRA>
References: <JIRA.12501342.1379980654000@Atlassian.JIRA>
	<JIRA.12501342.1379980654000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501342.1379980654000.61546.1472464981357@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-403:
-------------------------------------
    Labels: F2F2016  (was: )


> why decorator requires interface
> --------------------------------
>
>                 Key: CDI-403
>                 URL: https://issues.jboss.org/browse/CDI-403
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mathieu Lachance
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224),
> would it be possible to revisit why decorator requires an interface ?
> I do not understand the semantic difference between:
> 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. 
> 2. a decorator to be a concrete class which extends a another class, which delegates to the same class.
> Why 1. should be allowed and why 2. should be disallowed ?
> As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ?
> It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not.
> Thanks,



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 06:03:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 06:03:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-403) why decorator requires interface
In-Reply-To: <JIRA.12501342.1379980654000@Atlassian.JIRA>
References: <JIRA.12501342.1379980654000@Atlassian.JIRA>
	<JIRA.12501342.1379980654000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501342.1379980654000.61553.1472464981660@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-403:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> why decorator requires interface
> --------------------------------
>
>                 Key: CDI-403
>                 URL: https://issues.jboss.org/browse/CDI-403
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mathieu Lachance
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224),
> would it be possible to revisit why decorator requires an interface ?
> I do not understand the semantic difference between:
> 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. 
> 2. a decorator to be a concrete class which extends a another class, which delegates to the same class.
> Why 1. should be allowed and why 2. should be disallowed ?
> As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ?
> It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not.
> Thanks,



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 06:03:02 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 06:03:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-403) why decorator requires interface
In-Reply-To: <JIRA.12501342.1379980654000@Atlassian.JIRA>
References: <JIRA.12501342.1379980654000@Atlassian.JIRA>
	<JIRA.12501342.1379980654000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501342.1379980654000.61560.1472464982102@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-403:
-------------------------------------
    Issue Type: Feature Request  (was: Clarification)


> why decorator requires interface
> --------------------------------
>
>                 Key: CDI-403
>                 URL: https://issues.jboss.org/browse/CDI-403
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Mathieu Lachance
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224),
> would it be possible to revisit why decorator requires an interface ?
> I do not understand the semantic difference between:
> 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. 
> 2. a decorator to be a concrete class which extends a another class, which delegates to the same class.
> Why 1. should be allowed and why 2. should be disallowed ?
> As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ?
> It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not.
> Thanks,



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:08:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:08:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives
In-Reply-To: <JIRA.12525353.1384540464000@Atlassian.JIRA>
References: <JIRA.12525353.1384540464000@Atlassian.JIRA>
	<JIRA.12525353.1384540464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525353.1384540464000.63432.1472476080602@Atlassian.JIRA>


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

Antoine Sabot-Durand closed CDI-407.
------------------------------------
    Release Notes Text: @Specializes does the job
            Resolution: Rejected


> Specifiy @Named @Alternatives
> -----------------------------
>
>                 Key: CDI-407
>                 URL: https://issues.jboss.org/browse/CDI-407
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans, Inheritance and Specialization
>            Reporter: Thomas Andraschko
>
> It's actually a must-have for product development and a common case.
> We would like to have multiple implementations in our core and just activate them via alternative.
> I talked with struberg and its currently not defined in the specs.
> e.g.
> @Named public class A
> @Named @Alternative public class B extends A
> What should acutally happen if B is activated via beans.xml?
> IMO B should be available in EL via "a" and "b".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:16:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:16:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-415) Observer resolution doesn't
 specify handling of null parameter values
In-Reply-To: <JIRA.12530069.1390384029000@Atlassian.JIRA>
References: <JIRA.12530069.1390384029000@Atlassian.JIRA>
	<JIRA.12530069.1390384029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530069.1390384029000.63501.1472476561672@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-415:
-------------------------------------
    Labels: F2F2016  (was: )


> Observer resolution doesn't specify handling of null parameter values
> ---------------------------------------------------------------------
>
>                 Key: CDI-415
>                 URL: https://issues.jboss.org/browse/CDI-415
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>            Reporter: Michael Kotten
>            Priority: Minor
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> There is a gap in chapter 10.2 of the current CDI spec about [observer resolution|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution]. It doesn't specify what should happen if an event gets fired using a null value. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:16:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:16:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-415) Observer resolution doesn't
 specify handling of null parameter values
In-Reply-To: <JIRA.12530069.1390384029000@Atlassian.JIRA>
References: <JIRA.12530069.1390384029000@Atlassian.JIRA>
	<JIRA.12530069.1390384029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530069.1390384029000.63503.1472476561861@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-415:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> Observer resolution doesn't specify handling of null parameter values
> ---------------------------------------------------------------------
>
>                 Key: CDI-415
>                 URL: https://issues.jboss.org/browse/CDI-415
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>            Reporter: Michael Kotten
>            Priority: Minor
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> There is a gap in chapter 10.2 of the current CDI spec about [observer resolution|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution]. It doesn't specify what should happen if an event gets fired using a null value. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:26:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:26:00 -0400 (EDT)
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.63603.1472477160404@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-232:
-------------------------------------
    Labels: F2F2016  (was: )


> 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
>              Labels: F2F2016
>             Fix For: 2.0 (proposed)
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:31:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:31:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-233) Specify target bean archive for
 bean added via AfterBeanDiscovery.addBean()
In-Reply-To: <JIRA.12467388.1337953635000@Atlassian.JIRA>
References: <JIRA.12467388.1337953635000@Atlassian.JIRA>
	<JIRA.12467388.1337953635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467388.1337953635000.63668.1472477460751@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-233:
-------------------------------------
    Labels: F2F2016 visibility  (was: visibility)


> Specify target bean archive for bean added via AfterBeanDiscovery.addBean()
> ---------------------------------------------------------------------------
>
>                 Key: CDI-233
>                 URL: https://issues.jboss.org/browse/CDI-233
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Martin Kouba
>              Labels: F2F2016, visibility
>             Fix For: 2.0 (discussion)
>
>
> This may have impact, provided that alternatives, interceptors or decorators are used.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:31:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:31:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-233) Specify target bean archive for
 bean added via AfterBeanDiscovery.addBean()
In-Reply-To: <JIRA.12467388.1337953635000@Atlassian.JIRA>
References: <JIRA.12467388.1337953635000@Atlassian.JIRA>
	<JIRA.12467388.1337953635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467388.1337953635000.63673.1472477461307@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-233:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Specify target bean archive for bean added via AfterBeanDiscovery.addBean()
> ---------------------------------------------------------------------------
>
>                 Key: CDI-233
>                 URL: https://issues.jboss.org/browse/CDI-233
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Martin Kouba
>              Labels: F2F2016, visibility
>             Fix For: 2.0 (discussion)
>
>
> This may have impact, provided that alternatives, interceptors or decorators are used.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:33:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:33:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.63684.1472477580523@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-626:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Aug 29 09:33:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 29 Aug 2016 09:33:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-626) How should CDI.current() and
 CDI.getBeanManager() behave for non-CDI apps?
In-Reply-To: <JIRA.12644583.1472037594000@Atlassian.JIRA>
References: <JIRA.12644583.1472037594000@Atlassian.JIRA>
	<JIRA.12644583.1472037594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644583.1472037594000.63689.1472477581015@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-626:
-------------------------------------
    Labels: F2F2016  (was: )


> How should CDI.current() and CDI.getBeanManager() behave for non-CDI apps?
> --------------------------------------------------------------------------
>
>                 Key: CDI-626
>                 URL: https://issues.jboss.org/browse/CDI-626
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> We did hit the following situation: 
> A user installs a Spring application WAR file in TomEE. In that case we don't boot the CDI container. But the JSF Container calls CDI.current(). 
> How should CDI.current() behave in that case? Throwing an IllegalStateException, returning null or return a non-functional BeanManager?
> We should also define the behaviour of CDI.getBeanManager while we are at it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 04:40:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 30 Aug 2016 04:40:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-415) Observer resolution doesn't
 specify handling of null parameter values
In-Reply-To: <JIRA.12530069.1390384029000@Atlassian.JIRA>
References: <JIRA.12530069.1390384029000@Atlassian.JIRA>
	<JIRA.12530069.1390384029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530069.1390384029000.67968.1472546400853@Atlassian.JIRA>


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

Martin Kouba commented on CDI-415:
----------------------------------

Weld throws an {{IllegalArgumentException}} which is fine IMHO. Also I don't think this requires spec text change, a javadoc update would be enough. 

> Observer resolution doesn't specify handling of null parameter values
> ---------------------------------------------------------------------
>
>                 Key: CDI-415
>                 URL: https://issues.jboss.org/browse/CDI-415
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>            Reporter: Michael Kotten
>            Priority: Minor
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> There is a gap in chapter 10.2 of the current CDI spec about [observer resolution|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution]. It doesn't specify what should happen if an event gets fired using a null value. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 09:18:01 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 30 Aug 2016 09:18:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in
 typesafe resolution mechanism
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.72699.1472563081272@Atlassian.JIRA>


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

Tomas Remes commented on CDI-471:
---------------------------------

[~antoinesabot-durand] I think this should one of the issues with highest priority for upcoming CDI F2F meeting. WDYT?

> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 09:21:05 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 30 Aug 2016 09:21:05 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in
 typesafe resolution mechanism
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.72835.1472563265060@Atlassian.JIRA>


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

Tomas Remes edited comment on CDI-471 at 8/30/16 9:20 AM:
----------------------------------------------------------

[~antoinesabot-durand] I think this should be one of the issues with highest priority for upcoming CDI F2F meeting. WDYT?


was (Author: tremes):
[~antoinesabot-durand] I think this should one of the issues with highest priority for upcoming CDI F2F meeting. WDYT?

> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 09:35:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 30 Aug 2016 09:35:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in
 typesafe resolution mechanism
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.73134.1472564101392@Atlassian.JIRA>


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

Martin Kouba updated CDI-471:
-----------------------------
    Labels: F2F2016  (was: )


> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>              Labels: F2F2016
>
> 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
(v6.4.11#64026)

From antoine at sabot-durand.net  Tue Aug 30 10:20:46 2016
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 30 Aug 2016 14:20:46 +0000
Subject: [cdi-dev] Cancelling meeting today
Message-ID: <CABu-YBSeSfaRSphiNhnxejU6JSYV5RaNL7D7CpfRYH9PDWs5SA@mail.gmail.com>

Sorry, guys, I've got still a lot of work to do to prepare next week F2F
meeting and Java One Talks and meeting with other specs.

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

From issues at jboss.org  Tue Aug 30 10:32:05 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:32:05 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in
 typesafe resolution mechanism
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.74194.1472567525262@Atlassian.JIRA>


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

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

yes, it's on my list ;).

> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>              Labels: F2F2016
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:33:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:33:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with
 @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
In-Reply-To: <JIRA.12644548.1472028968000@Atlassian.JIRA>
References: <JIRA.12644548.1472028968000@Atlassian.JIRA>
	<JIRA.12644548.1472028968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644548.1472028968000.74205.1472567580442@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-625:
-------------------------------------
    Labels: F2F2016  (was: )


> When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
> -------------------------------------------------------------------------------------------
>
>                 Key: CDI-625
>                 URL: https://issues.jboss.org/browse/CDI-625
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>            Reporter: Martin Kouba
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). 
> Does it mean that:
> * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?
> I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.
> In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.
> I believe this should be more clear.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:33:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:33:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-625) When exactly are events with
 @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
In-Reply-To: <JIRA.12644548.1472028968000@Atlassian.JIRA>
References: <JIRA.12644548.1472028968000@Atlassian.JIRA>
	<JIRA.12644548.1472028968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644548.1472028968000.74207.1472567580492@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-625:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
> -------------------------------------------------------------------------------------------
>
>                 Key: CDI-625
>                 URL: https://issues.jboss.org/browse/CDI-625
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>            Reporter: Martin Kouba
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> The spec states that {{@Initialized(X.class)}} is fired when a context is initialized and {{@Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_). 
> Does it mean that:
> * {{@Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{@Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?
> I'm asking because for {{@Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.
> In RI/Weld, the behaivour of {{@Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.
> I believe this should be more clear.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:38:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:38:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.74282.1472567880731@Atlassian.JIRA>


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

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

Agree with Tomas and John. They should be removed (2nd solution). Dynamic extension is a better feature to focus on IMO.

> Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-624
>                 URL: https://issues.jboss.org/browse/CDI-624
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>              Labels: F2F2016
>
> I believe we should not break the application initialization lifecycle. 
> So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.
> The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:38:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:38:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.74286.1472567880947@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-624:
-------------------------------------
    Labels: F2F2016  (was: )


> Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-624
>                 URL: https://issues.jboss.org/browse/CDI-624
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>              Labels: F2F2016
>
> I believe we should not break the application initialization lifecycle. 
> So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.
> The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:39:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:39:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-624) Map
 SeContainerInitializer.addBeans() and
 SeContainerInitializer.addAnnotatedTypes() to the application
 initialization lifecycle
In-Reply-To: <JIRA.12642896.1470904208000@Atlassian.JIRA>
References: <JIRA.12642896.1470904208000@Atlassian.JIRA>
	<JIRA.12642896.1470904208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642896.1470904208000.74290.1472567940331@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-624:
-------------------------------------
    Fix Version/s: 2.0 (proposed)


> Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-624
>                 URL: https://issues.jboss.org/browse/CDI-624
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java SE Integration
>    Affects Versions: 2.0-EDR2
>            Reporter: Martin Kouba
>              Labels: F2F2016
>             Fix For: 2.0 (proposed)
>
>
> I believe we should not break the application initialization lifecycle. 
> So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}.
> The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:48:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:48:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.74422.1472568480500@Atlassian.JIRA>


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

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

I guess that [~meetoblivion] is talking of the case were a configurator is requested and the user doesn't do anything with it.
That's good point, since the "build" method of these builder is hidden we still have to specify what is the minimum info we have to add to these configurators to be able to build them.

So we need:

# specify what is the minimum configuration user has to put in a {{BeanConfigurator}} and {{ObserverMethodConfigurator}} to make them viable. Propbaly the same for toher configurator
# what shoudl be the behaviour ot eh container in case of a non viable Configurator (abd.add*()) was called and nothing (or non mimimum requirement) was done with the returned configurator. ISE seems to be the best choice here

> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:48:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:48:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.74428.1472568480743@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-623:
-------------------------------------
    Labels: F2F2016  (was: )


> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:49:04 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 30 Aug 2016 10:49:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.74473.1472568544173@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-623:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 10:53:01 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 30 Aug 2016 10:53:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.74577.1472568781285@Atlassian.JIRA>


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

John Ament commented on CDI-623:
--------------------------------

[~antoinesabot-durand] yep, exactly.

> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Aug 30 11:07:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 30 Aug 2016 11:07:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.74805.1472569621761@Atlassian.JIRA>


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

Martin Kouba commented on CDI-623:
----------------------------------

I'm not sure we should specify this. But if we do then we should probably use the same requirements/validation rules for non-configurator methods as well, e.g. for  {{AfterBeanDiscoveryImpl.addBean(Bean<?>)}}. Actually, in Weld we already do some simple validation and e.g. throw {{DefinitionException}} if {{getBeanClass()}} returns null.

> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 02:15:01 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Wed, 31 Aug 2016 02:15:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.78175.1472624101174@Atlassian.JIRA>


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

Matej Novotny commented on CDI-623:
-----------------------------------

I am fine with saying that obtaining a configurator without doing actual work doesn't make sense and we should throw an exception (ISE most likely).
However I am not convinced we should describe the minimum info as that can get pretty complex especially if combined with {{read}} methods. (Which sort of leads to https://issues.jboss.org/browse/CDI-614)

> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 04:44:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 31 Aug 2016 04:44:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.78767.1472633040203@Atlassian.JIRA>


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

Antoine Sabot-Durand edited comment on CDI-623 at 8/31/16 4:43 AM:
-------------------------------------------------------------------

I guess that [~meetoblivion] is talking of the case were a configurator is requested and the user doesn't do anything with it.
That's good point, since the "build" method of these builder is hidden we still have to specify what is the minimum info we have to add to these configurators to be able to build them.

So we need:

# specify what is the minimum configuration user has to put in a {{BeanConfigurator}} and {{ObserverMethodConfigurator}} to make them viable. Probably the same for other configurators
# what should be the behaviour of the container in case of a non viable Configurator (abd.add*()) was called and nothing (or non mimimum requirement) was done with the returned configurator. ISE seems to be the best choice here


was (Author: antoinesabot-durand):
I guess that [~meetoblivion] is talking of the case were a configurator is requested and the user doesn't do anything with it.
That's good point, since the "build" method of these builder is hidden we still have to specify what is the minimum info we have to add to these configurators to be able to build them.

So we need:

# specify what is the minimum configuration user has to put in a {{BeanConfigurator}} and {{ObserverMethodConfigurator}} to make them viable. Propbaly the same for toher configurator
# what shoudl be the behaviour ot eh container in case of a non viable Configurator (abd.add*()) was called and nothing (or non mimimum requirement) was done with the returned configurator. ISE seems to be the best choice here

> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:02:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 31 Aug 2016 06:02:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-623) Specify what happens when calling
 addObserverMethod or addBean alone
In-Reply-To: <JIRA.12638266.1468195302000@Atlassian.JIRA>
References: <JIRA.12638266.1468195302000@Atlassian.JIRA>
	<JIRA.12638266.1468195302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638266.1468195302000.79998.1472637721111@Atlassian.JIRA>


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

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

[~manovotn], [~mkouba], I think we are mixing 2 illegal state here:

* A defined bean that is illegal. This ticket shouldn't change nothing about this
* A bean to build thru a configurator that was not defined (which has no defined type set or code to create instances).

Second case is our matter here. Now,I agree that it may be difficult to specify the minimum required to have a configurator ready to create a defined bean. Anyway implementation will have to do this.
Calling {{BeforeBeanDiscovery.addAnnotatedType()}} without using the returned configurator should trigger an exception at the end of BBD invocation.

> Specify what happens when calling addObserverMethod or addBean alone
> --------------------------------------------------------------------
>
>                 Key: CDI-623
>                 URL: https://issues.jboss.org/browse/CDI-623
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> AfterBeanDiscovery exposes methods addObserverMethod and addBean.  Both essentially leave dangling configurations that are not usable.
> I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:02:01 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 31 Aug 2016 06:02:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-471) Support repeating qualifiers in
 typesafe resolution mechanism
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.80003.1472637721647@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-471:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
>                 Key: CDI-471
>                 URL: https://issues.jboss.org/browse/CDI-471
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>            Reporter: Antonin Stefanutti
>              Labels: F2F2016
>             Fix For: 2.0 (discussion)
>
>
> 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
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:05:02 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 31 Aug 2016 06:05:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll method can lead to
	ambiguities
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.80097.1472637902735@Atlassian.JIRA>


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

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

[~meetoblivion] as Martin and Matej already said, your ambiguity is... ambiguous ;). Could you detail please.

> removeAll method can lead to ambiguities
> ----------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 31 Aug 2016 06:09:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an
 annotated type is.
In-Reply-To: <JIRA.12637363.1467551710000@Atlassian.JIRA>
References: <JIRA.12637363.1467551710000@Atlassian.JIRA>
	<JIRA.12637363.1467551710000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637363.1467551710000.80170.1472638140363@Atlassian.JIRA>


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

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

Yes we should change parameter order.

> Not clear what the id for an annotated type is.
> -----------------------------------------------
>
>                 Key: CDI-620
>                 URL: https://issues.jboss.org/browse/CDI-620
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (proposed)
>
>
> The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is.
> In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 31 Aug 2016 06:09:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an
 annotated type is.
In-Reply-To: <JIRA.12637363.1467551710000@Atlassian.JIRA>
References: <JIRA.12637363.1467551710000@Atlassian.JIRA>
	<JIRA.12637363.1467551710000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637363.1467551710000.80174.1472638140589@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-620:
-------------------------------------
    Labels: F2F2016  (was: )


> Not clear what the id for an annotated type is.
> -----------------------------------------------
>
>                 Key: CDI-620
>                 URL: https://issues.jboss.org/browse/CDI-620
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (proposed)
>
>
> The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is.
> In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:09:00 2016
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 31 Aug 2016 06:09:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-620) Not clear what the id for an
 annotated type is.
In-Reply-To: <JIRA.12637363.1467551710000@Atlassian.JIRA>
References: <JIRA.12637363.1467551710000@Atlassian.JIRA>
	<JIRA.12637363.1467551710000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637363.1467551710000.80178.1472638140755@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-620:
-------------------------------------
    Fix Version/s: 2.0 (proposed)
                       (was: 2.0 (discussion))


> Not clear what the id for an annotated type is.
> -----------------------------------------------
>
>                 Key: CDI-620
>                 URL: https://issues.jboss.org/browse/CDI-620
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>              Labels: F2F2016
>             Fix For: 2.0 (proposed)
>
>
> The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is.
> In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:33:10 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 31 Aug 2016 06:33:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll method can lead to
	ambiguities
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.80576.1472639590955@Atlassian.JIRA>


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

John Ament commented on CDI-621:
--------------------------------

Its not clear from looking at the method name that only the annotations are removed.  It might be better to call it something like {{clearAnnotations}} or similar.  As mentioned, the other two are not an issue, since they're explicitly taking annotation parameters when doing their remove.  Again, this is all from my POV.

> removeAll method can lead to ambiguities
> ----------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:37:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 31 Aug 2016 06:37:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll method can lead to
	ambiguities
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.80670.1472639820339@Atlassian.JIRA>


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

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

what about ignoreAnnotations() or ignoreReflection() (a bit like ignoreXmlConfiguration() in bean validation Configuration<?>)

> removeAll method can lead to ambiguities
> ----------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:38:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 31 Aug 2016 06:38:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621)
 AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.80677.1472639880159@Atlassian.JIRA>


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

Martin Kouba updated CDI-621:
-----------------------------
    Summary: AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities  (was: removeAll method can lead to ambiguities)


> AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities
> --------------------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:42:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 31 Aug 2016 06:42:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621)
 AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.80699.1472640121001@Atlassian.JIRA>


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

Martin Kouba commented on CDI-621:
----------------------------------

Well, the point is the {{AnnotatedTypeConfigurator}} and firends ({{AnnotatedMethodConfigurator}}, ...) can ONLY be used to modify/configure annotations. So it's implicit. Also the javadoc is clear. 

> AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities
> --------------------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 06:47:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 31 Aug 2016 06:47:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621)
 AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.80762.1472640421214@Atlassian.JIRA>


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

Martin Kouba edited comment on CDI-621 at 8/31/16 6:46 AM:
-----------------------------------------------------------

Well, the point is the {{AnnotatedTypeConfigurator}} and friends ({{AnnotatedMethodConfigurator}}, etc.) can ONLY be used to modify/configure annotations. So it's implicit. Also the javadoc is clear. 


was (Author: mkouba):
Well, the point is the {{AnnotatedTypeConfigurator}} and firends ({{AnnotatedMethodConfigurator}}, ...) can ONLY be used to modify/configure annotations. So it's implicit. Also the javadoc is clear. 

> AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities
> --------------------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 07:15:03 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 31 Aug 2016 07:15:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll() method is ambiguous in
 multiple configurators.
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.81263.1472642103309@Atlassian.JIRA>


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

John Ament updated CDI-621:
---------------------------
    Summary: removeAll() method is ambiguous in multiple configurators.  (was: AnnotatedTypeConfigurator.removeAll() method can lead to ambiguities)


> removeAll() method is ambiguous in multiple configurators.
> ----------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 07:16:02 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 31 Aug 2016 07:16:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll() method is ambiguous in
 multiple configurators.
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.81308.1472642162925@Atlassian.JIRA>


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

John Ament commented on CDI-621:
--------------------------------

Take a look at https://github.com/cdi-spec/cdi/blob/2.0-EDR2/api/src/main/java/javax/enterprise/inject/spi/builder/AnnotatedTypeConfigurator.java and let me know if you think as a user, you're only configuring annotations.

> removeAll() method is ambiguous in multiple configurators.
> ----------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 07:28:02 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 31 Aug 2016 07:28:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll() method is ambiguous in
 multiple configurators.
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.81463.1472642882608@Atlassian.JIRA>


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

Martin Kouba commented on CDI-621:
----------------------------------

Yes, only annotations of the type and its members. The sets of members are immutable (mentioned in javadoc) and the same applies to streams. If it's not clear we should mention this in the class javadoc and improve the "AnnotatedTypeConfigurator SPI" section.

> removeAll() method is ambiguous in multiple configurators.
> ----------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 07:37:00 2016
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 31 Aug 2016 07:37:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll() method is ambiguous in
 multiple configurators.
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.81514.1472643420280@Atlassian.JIRA>


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

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

[~mkouba] I tend to join John on that, if you need to check the javadoc to understand what a method does the method is likely badly named. Also the renaming is quite trivial and would benefit user experience in IDE (you dont need to go on all methods to read the javadoc to know which one you need to use)

> removeAll() method is ambiguous in multiple configurators.
> ----------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 08:02:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 31 Aug 2016 08:02:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll() method is ambiguous in
 multiple configurators.
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.81636.1472644920609@Atlassian.JIRA>


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

Martin Kouba commented on CDI-621:
----------------------------------

Feel free to rename it. But from my POV {{removeAllAnnotations()}} and similar would be a bad name because a user might expect to be able to remove other things than annotations and that's what {{AnnotatedTypeConfigurator}} is not allowed to do or intended for. So I still believe it would be more meaningful to emphasize that {{AnnotatedTypeConfigurator}} works only with annotations and that's it.

> removeAll() method is ambiguous in multiple configurators.
> ----------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 08:45:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 31 Aug 2016 08:45:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll() method is ambiguous in
 multiple configurators.
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.81941.1472647500379@Atlassian.JIRA>


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

John Ament commented on CDI-621:
--------------------------------

Today the only thing you can remove is annotations.  Maybe at a later point you can change other things.  When you can, what does {{removeAll}} mean?

> removeAll() method is ambiguous in multiple configurators.
> ----------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Aug 31 09:00:01 2016
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Wed, 31 Aug 2016 09:00:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-621) removeAll() method is ambiguous in
 multiple configurators.
In-Reply-To: <JIRA.12637364.1467551929000@Atlassian.JIRA>
References: <JIRA.12637364.1467551929000@Atlassian.JIRA>
	<JIRA.12637364.1467551929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12637364.1467551929000.82018.1472648401328@Atlassian.JIRA>


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

Matej Novotny commented on CDI-621:
-----------------------------------

bq. Maybe at a later point you can change other things...
At that later point, should it ever come to that, you need merely mark {{removeAll}} as deprecated and delegate its' call to newly created {{removeAllAnnotations}} method.
But if you really feel like having it right away makes things easier, I am not against it. From my POV its not such a big deal.

> removeAll() method is ambiguous in multiple configurators.
> ----------------------------------------------------------
>
>                 Key: CDI-621
>                 URL: https://issues.jboss.org/browse/CDI-621
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: John Ament
>
> The method removeAll is ambiguous.  This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe.  The removeAll method presupposes that annotations are the only thing to configure.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)