From antoine at sabot-durand.net  Mon Mar  3 11:20:21 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 3 Mar 2014 17:20:21 +0100
Subject: [cdi-dev] Regarding CDI-280 and beans terminology
Message-ID: <FBD3E321-1CD1-40F0-9821-3F7E72A327FB@sabot-durand.net>

Hi all,

I really think we should work for terminology simplification but I wonder if it?s realistic in our timeframe.  According to me the easy part is :

 - ? Bean Class ?  for the class that gets Scanned : *Bean Class* (_quite obvious_)
 - ? Bean Metadata for Bean<T> : *Bean Metadata* using ? Bean ? here is confusing)
 - ? Required Type ? for the type of injection type
 - ?  Session Bean ?  for EJB bean

Now the more complex part is for the biggest one. From my understanding we have 2 concept with at least 3 different names :

- Contextual Instance = Bean Instance = Bean
- Contextual Reference = Client Proxy = Bean Reference

I I?m not wrong on this classification, we should really choose an official name for these 2  concepts

My personal choice would be ? Bean Instance ? and ?  Bean Reference ? with perhaps a link to contextual names in chapter 6.

The term ? Bean ? could be reserved to mean one to the other when difference is not relevant?

What do you think ?

 
Antoine Sabot-Durand
???????????????
Twitter : @antoine_sd
CDI co-spec lead & eco-system development
Agorava tech lead

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140303/6e90e441/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140303/6e90e441/attachment.bin 

From mkouba at redhat.com  Mon Mar  3 11:39:40 2014
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 03 Mar 2014 17:39:40 +0100
Subject: [cdi-dev] Regarding CDI-280 and beans terminology
In-Reply-To: <FBD3E321-1CD1-40F0-9821-3F7E72A327FB@sabot-durand.net>
References: <FBD3E321-1CD1-40F0-9821-3F7E72A327FB@sabot-durand.net>
Message-ID: <5314B04C.30909@redhat.com>

Dne 3.3.2014 17:20, Antoine Sabot-Durand napsal(a):
> Hi all,
> 
> I really think we should work for terminology simplification but I
> wonder if it?s realistic in our timeframe.  According to me the easy
> part is :
> 
>  - ? Bean Class ?  for the class that gets Scanned : *Bean Class*
> (_quite obvious_)
>  - ? Bean Metadata for Bean<T> : *Bean Metadata* using ? Bean ? here is
> confusing)
>  - ? Required Type ? for the type of injection type
>  - ?  Session Bean ?  for EJB bean
> 
> Now the more complex part is for the biggest one. From my understanding
> we have 2 concept with at least 3 different names :
> 
> - Contextual Instance = Bean Instance = Bean
> - Contextual Reference = Client Proxy = Bean Reference

But contextual instance != bean instance as Contextual<T> != Bean<T>, right?

> 
> I I?m not wrong on this classification, we should really choose an
> official name for these 2  concepts
> 
> My personal choice would be ? Bean Instance ? and ?  Bean Reference ?
> with perhaps a link to contextual names in chapter 6.
> 
> The term ? Bean ? could be reserved to mean one to the other when
> difference is not relevant?
> 
> What do you think ?
> 
>  
> Antoine Sabot-Durand
> ???????????????
> Twitter : @antoine_sd
> CDI co-spec lead & eco-system development
> Agorava tech lead
> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 

From antoine at sabot-durand.net  Mon Mar  3 11:56:34 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 3 Mar 2014 17:56:34 +0100
Subject: [cdi-dev] Regarding CDI-280 and beans terminology
In-Reply-To: <5314B04C.30909@redhat.com>
References: <FBD3E321-1CD1-40F0-9821-3F7E72A327FB@sabot-durand.net>
	<5314B04C.30909@redhat.com>
Message-ID: <B7B05A16-582D-4A5D-A089-0A85DF9BE815@sabot-durand.net>


Le 3 mars 2014 ? 17:39, Martin Kouba <mkouba at redhat.com> a ?crit :

> Dne 3.3.2014 17:20, Antoine Sabot-Durand napsal(a):
>> Hi all,
>> 
>> I really think we should work for terminology simplification but I
>> wonder if it?s realistic in our timeframe.  According to me the easy
>> part is :
>> 
>> - ? Bean Class ?  for the class that gets Scanned : *Bean Class*
>> (_quite obvious_)
>> - ? Bean Metadata for Bean<T> : *Bean Metadata* using ? Bean ? here is
>> confusing)
>> - ? Required Type ? for the type of injection type
>> - ?  Session Bean ?  for EJB bean
>> 
>> Now the more complex part is for the biggest one. From my understanding
>> we have 2 concept with at least 3 different names :
>> 
>> - Contextual Instance = Bean Instance = Bean
>> - Contextual Reference = Client Proxy = Bean Reference
> 
> But contextual instance != bean instance as Contextual<T> != Bean<T>, right?


Good question but I think that Contextual<T> is called "Instance of contextual" in the Spec. But not clear. when reading 6.5.2 [1] a lot of things are mixed up

[1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#contextual_instance

> 
>> 
>> I I?m not wrong on this classification, we should really choose an
>> official name for these 2  concepts
>> 
>> My personal choice would be ? Bean Instance ? and ?  Bean Reference ?
>> with perhaps a link to contextual names in chapter 6.
>> 
>> The term ? Bean ? could be reserved to mean one to the other when
>> difference is not relevant?
>> 
>> What do you think ?
>> 
>> 
>> Antoine Sabot-Durand
>> ???????????????
>> Twitter : @antoine_sd
>> CDI co-spec lead & eco-system development
>> Agorava tech lead
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev

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

From issues at jboss.org  Tue Mar  4 04:49:34 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 04:49:34 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation
 processing problematic
In-Reply-To: <JIRA.12494334.1371230850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494334.1371230850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494334.1371230850000.398.1393926574879@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reopened CDI-377:
--------------------------------------


    
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
>                 Key: CDI-377
>                 URL: https://issues.jboss.org/browse/CDI-377
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.PFD
>         Environment: glassfish-4
>            Reporter: Reuben Pasquini
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container 
> results in CDI processing annotated classes intended for 
> app-managed injection.  See this ticket filed with guava for a concrete example:
>     https://code.google.com/p/guava-libraries/issues/detail?id=1433

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 05:03:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 05:03:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-422) Wrong example for event qualifier
 types with members
In-Reply-To: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532888.1392971839000.459.1393927413525@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-422:
-------------------------------------

    Fix Version/s: 1.2 Proposed

    
> Wrong example for event qualifier types with members
> ----------------------------------------------------
>
>                 Key: CDI-422
>                 URL: https://issues.jboss.org/browse/CDI-422
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Events
>            Reporter: Martin Kouba
>            Priority: Minor
>             Fix For: 1.2 Proposed
>
>
> The following snippet in "10.2.2 Event qualifier types with members" is wrong:
> {code}
> public void login() {
> final User user = ...;
> loggedInEvent.fire( new LoggedInEvent(user),
> new RoleQualifier() { public String value() { return user.getRole(); } );
> }
> {code}
> {{javax.enterprise.event.Event.fire()}} method does not have qualifiers param. The example should either use {{Event.select(Annotation...)}} along with  {{Event.fire()}} or {{BeanManager.fireEvent(Object, Annotation...)}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 05:03:34 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 05:03:34 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-422) Wrong example for event qualifier
 types with members
In-Reply-To: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532888.1392971839000.469.1393927414263@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-422:
-------------------------------------

    Labels: CDI_spec_chge  (was: )

    
> Wrong example for event qualifier types with members
> ----------------------------------------------------
>
>                 Key: CDI-422
>                 URL: https://issues.jboss.org/browse/CDI-422
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Events
>            Reporter: Martin Kouba
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> The following snippet in "10.2.2 Event qualifier types with members" is wrong:
> {code}
> public void login() {
> final User user = ...;
> loggedInEvent.fire( new LoggedInEvent(user),
> new RoleQualifier() { public String value() { return user.getRole(); } );
> }
> {code}
> {{javax.enterprise.event.Event.fire()}} method does not have qualifiers param. The example should either use {{Event.select(Annotation...)}} along with  {{Event.fire()}} or {{BeanManager.fireEvent(Object, Annotation...)}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 05:51:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 05:51:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-422) Wrong example for event qualifier
 types with members
In-Reply-To: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532888.1392971839000.623.1393930293895@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Right [~mkouba]. Nice catch ;). I added this to 1.2.
I have two remarks on this :

# There are other wrong example after this one assuming the existence of this qualifier param in {{javax.enterprise.event.Event.fire()}} method. In 10.2.3 for instance 
   {code}
   documentEvent.fire( document, new UpdatedQualifier() {}, new ByAdminQualifier() {} );
   {code}
# After the correction, theses examples, in order to be valid, should add {{@Inject @Any Event<LoggedInEvent> loggedInEvent;}} . But the notion of Injecting {{@Any Event<T>}} is introduced in part _10.3 Firing events_. To make the chapter easier to understand I propose to switch 10.2 and 10.3 (it doesn't sound stupid to deal with firing event before dealing with observer by the way).

                
> Wrong example for event qualifier types with members
> ----------------------------------------------------
>
>                 Key: CDI-422
>                 URL: https://issues.jboss.org/browse/CDI-422
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Events
>            Reporter: Martin Kouba
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> The following snippet in "10.2.2 Event qualifier types with members" is wrong:
> {code}
> public void login() {
> final User user = ...;
> loggedInEvent.fire( new LoggedInEvent(user),
> new RoleQualifier() { public String value() { return user.getRole(); } );
> }
> {code}
> {{javax.enterprise.event.Event.fire()}} method does not have qualifiers param. The example should either use {{Event.select(Annotation...)}} along with  {{Event.fire()}} or {{BeanManager.fireEvent(Object, Annotation...)}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 05:57:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 05:57:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-422) Wrong example for event qualifier
 types with members
In-Reply-To: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532888.1392971839000.658.1393930653172@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-422:
----------------------------------------

    Assignee: Martin Kouba

    
> Wrong example for event qualifier types with members
> ----------------------------------------------------
>
>                 Key: CDI-422
>                 URL: https://issues.jboss.org/browse/CDI-422
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Events
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> The following snippet in "10.2.2 Event qualifier types with members" is wrong:
> {code}
> public void login() {
> final User user = ...;
> loggedInEvent.fire( new LoggedInEvent(user),
> new RoleQualifier() { public String value() { return user.getRole(); } );
> }
> {code}
> {{javax.enterprise.event.Event.fire()}} method does not have qualifiers param. The example should either use {{Event.select(Annotation...)}} along with  {{Event.fire()}} or {{BeanManager.fireEvent(Object, Annotation...)}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 06:03:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 06:03:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-401) Clarify the meaning of "bean class
 local view"
In-Reply-To: <JIRA.12500801.1379363355000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500801.1379363355000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500801.1379363355000.695.1393931013797@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-401:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Clarify the meaning of "bean class local view"
> ----------------------------------------------
>
>                 Key: CDI-401
>                 URL: https://issues.jboss.org/browse/CDI-401
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> 3.2.2 Bean types of a session bean:
> {quote}
> The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a *bean class local view*, the unrestricted set of bean types contains the bean class and all superclasses.
> ...
> {quote}
> AFAIK the EJB spec does not define anything like "bean class local view". I believe the CDI spec is referencing *No-Interface View* here (a variation of the local view that exposes the non-static public methods of the bean class without the use of a separate business interface).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 06:05:34 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 06:05:34 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-397) Clarify Section 6.6.3 regarding
	singletons
In-Reply-To: <JIRA.12499414.1377587184000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499414.1377587184000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499414.1377587184000.704.1393931134031@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-397:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Clarify Section 6.6.3 regarding singletons
> ------------------------------------------
>
>                 Key: CDI-397
>                 URL: https://issues.jboss.org/browse/CDI-397
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The section 6.6.3 Passivation capable dependencies states:
> {quote}
> all singleton beans are passivation capable dependencies
> {quote}
> Clearly the specification intents to address *singleton session beans* but the current wording does not make that explicit and users confuse this line and consider javax.inject.Singleton-scoped beans also to be passivation capable dependencies.
> The spec should instead say that:
> {quote}
> all singleton *session* beans are passivation capable dependencies
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 08:25:34 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 08:25:34 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-401) Clarify the meaning of "bean class
 local view"
In-Reply-To: <JIRA.12500801.1379363355000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500801.1379363355000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500801.1379363355000.1157.1393939534182@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-401 started by Antoine Sabot-Durand.

> Clarify the meaning of "bean class local view"
> ----------------------------------------------
>
>                 Key: CDI-401
>                 URL: https://issues.jboss.org/browse/CDI-401
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> 3.2.2 Bean types of a session bean:
> {quote}
> The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a *bean class local view*, the unrestricted set of bean types contains the bean class and all superclasses.
> ...
> {quote}
> AFAIK the EJB spec does not define anything like "bean class local view". I believe the CDI spec is referencing *No-Interface View* here (a variation of the local view that exposes the non-static public methods of the bean class without the use of a separate business interface).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar  4 08:47:34 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 4 Mar 2014 08:47:34 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-397) Clarify Section 6.6.3 regarding
	singletons
In-Reply-To: <JIRA.12499414.1377587184000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499414.1377587184000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499414.1377587184000.1276.1393940854695@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-397 started by Antoine Sabot-Durand.

> Clarify Section 6.6.3 regarding singletons
> ------------------------------------------
>
>                 Key: CDI-397
>                 URL: https://issues.jboss.org/browse/CDI-397
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The section 6.6.3 Passivation capable dependencies states:
> {quote}
> all singleton beans are passivation capable dependencies
> {quote}
> Clearly the specification intents to address *singleton session beans* but the current wording does not make that explicit and users confuse this line and consider javax.inject.Singleton-scoped beans also to be passivation capable dependencies.
> The spec should instead say that:
> {quote}
> all singleton *session* beans are passivation capable dependencies
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar  5 03:25:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 5 Mar 2014 03:25:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.3750.1394007933315@jira02.app.mwc.hst.phx2.redhat.com>


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

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

I guess this ambiguous behavior 
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar  5 03:25:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 5 Mar 2014 03:25:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.3757.1394007933639@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-392:
-------------------------------------

    Comment: was deleted

(was: I guess this ambiguous behavior )

    
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar  5 03:27:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 5 Mar 2014 03:27:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-376) BeanManager#getProducerFactory
 return type differs between API and spec
In-Reply-To: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494292.1371206687000.3767.1394008053133@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-376:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
>                 Key: CDI-376
>                 URL: https://issues.jboss.org/browse/CDI-376
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.1.PFD
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>            Priority: Critical
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have 
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar  5 03:53:34 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 5 Mar 2014 03:53:34 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-376) BeanManager#getProducerFactory
 return type differs between API and spec
In-Reply-To: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494292.1371206687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494292.1371206687000.3828.1394009614149@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-376 started by Antoine Sabot-Durand.

> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
>                 Key: CDI-376
>                 URL: https://issues.jboss.org/browse/CDI-376
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Javadoc and API
>    Affects Versions: 1.1.PFD
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>            Priority: Critical
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> In API we have
> {{public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> While in spec (section 11.3.22 )we have 
> {{public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);}}
> They differ in the return type:
> {{ProducerFactory<X>}} vs {{ProducerFactory<? super X>}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar  5 04:09:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 5 Mar 2014 04:09:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-423) Typo in section 11.3.26
In-Reply-To: <JIRA.12533021.1393102555000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12533021.1393102555000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533021.1393102555000.3875.1394010573788@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-423:
-------------------------------------

    Fix Version/s: 1.2 Proposed

    
> Typo in section 11.3.26
> -----------------------
>
>                 Key: CDI-423
>                 URL: https://issues.jboss.org/browse/CDI-423
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: John Ament
>            Priority: Minor
>             Fix For: 1.2 Proposed
>
>
> There is a typo in 11.3.26
> http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bm_obtain_extension
> The method BeanManager.getExtensions() returns the container?s instance of an Extension class 
> Should be: The method `BeanManager.getExtension(Class<? extends Extension> clazz)` 
> This matches API docs and the verbiage at the end of the spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Mar  5 04:31:34 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 5 Mar 2014 04:31:34 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-422) Wrong example for event qualifier
 types with members
In-Reply-To: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12532888.1392971839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532888.1392971839000.4045.1394011894695@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba commented on CDI-422:
----------------------------------

I've updated the pull request with proposed changes.
                
> Wrong example for event qualifier types with members
> ----------------------------------------------------
>
>                 Key: CDI-422
>                 URL: https://issues.jboss.org/browse/CDI-422
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Events
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> The following snippet in "10.2.2 Event qualifier types with members" is wrong:
> {code}
> public void login() {
> final User user = ...;
> loggedInEvent.fire( new LoggedInEvent(user),
> new RoleQualifier() { public String value() { return user.getRole(); } );
> }
> {code}
> {{javax.enterprise.event.Event.fire()}} method does not have qualifiers param. The example should either use {{Event.select(Annotation...)}} along with  {{Event.fire()}} or {{BeanManager.fireEvent(Object, Annotation...)}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar  5 09:47:36 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 5 Mar 2014 09:47:36 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-424) Add validation of contextuals
 passed to a context object for a passivating scope
In-Reply-To: <JIRA.12534179.1394030849155@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534179.1394030849155@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534179.1394030849155.5282.1394030856069@jira02.app.mwc.hst.phx2.redhat.com>

Martin Kouba created CDI-424:
--------------------------------

             Summary: Add validation of contextuals passed to a context object for a passivating scope
                 Key: CDI-424
                 URL: https://issues.jboss.org/browse/CDI-424
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba


6.6.1 Passivation capable beans:
{quote}
An implementation of Contextual that is not a bean is passivation capable if it implements both PassivationCapable and Serializable.
{quote}
6.6.4 Passivating scopes
{quote}
A passivating scope requires that implementations of Contextual passed to any context object for the scope are passivation capable.
{quote}

Theoretically an implementation of Contextual that is not a bean may be passed to a context object of a passivating scope (e.g. @SessionScoped). The spec should specify what happens then. Apparently the container should detect the problem and treat it as a deployment problem. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Thu Mar  6 06:51:24 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 6 Mar 2014 12:51:24 +0100
Subject: [cdi-dev] Tests on observer resolution
Message-ID: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>

Hi all


Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you?re interested you can check the transcript [3] from 09:43.

To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]

Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
The only strange thing for me is that @Any seems totally useless regarding events firing

If you write : 
@Inject Event<Payload> payLoadEvent;
or
@Inject @Any Event<Payload> payLoadEvent;

You?ll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...

Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification?

Antoine

[1] https://github.com/cdi-spec/cdi/pull/207
[2] https://issues.jboss.org/browse/CDI-422
[3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
[4] https://github.com/antoinesd/EventsTest
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140306/68758683/attachment-0001.bin 

From issues at jboss.org  Thu Mar  6 10:10:33 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 6 Mar 2014 10:10:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-425) At runtime invocation of any
 container lifecycle event method should result in exception
In-Reply-To: <JIRA.12534295.1394118564814@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534295.1394118564814@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534295.1394118564814.9269.1394118633463@jira02.app.mwc.hst.phx2.redhat.com>

Martin Kouba created CDI-425:
--------------------------------

             Summary: At runtime invocation of any container lifecycle event method should result in exception
                 Key: CDI-425
                 URL: https://issues.jboss.org/browse/CDI-425
             Project: CDI Specification Issues
          Issue Type: Clarification
    Affects Versions: 1.1.Final
            Reporter: Martin Kouba


At runtime (after AfterDeploymentValidation event is fired) invocation of container lifecycle event methods should be explicitly forbidden and result in exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar  6 10:10:33 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 6 Mar 2014 10:10:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-425) At runtime invocation of any
 container lifecycle event method should result in exception
In-Reply-To: <JIRA.12534295.1394118564000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534295.1394118564000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534295.1394118564000.9270.1394118633504@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba updated CDI-425:
-----------------------------

    Forum Reference: http://lists.jboss.org/pipermail/weld-dev/2014-March/003219.html

    
> At runtime invocation of any container lifecycle event method should result in exception
> ----------------------------------------------------------------------------------------
>
>                 Key: CDI-425
>                 URL: https://issues.jboss.org/browse/CDI-425
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.Final
>            Reporter: Martin Kouba
>
> At runtime (after AfterDeploymentValidation event is fired) invocation of container lifecycle event methods should be explicitly forbidden and result in exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar  6 10:12:33 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 6 Mar 2014 10:12:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-425) Invocation of any container
 lifecycle event method at runtime should result in exception
In-Reply-To: <JIRA.12534295.1394118564000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534295.1394118564000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534295.1394118564000.9271.1394118753080@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba updated CDI-425:
-----------------------------

    Summary: Invocation of any container lifecycle event method at runtime should result in exception  (was: At runtime invocation of any container lifecycle event method should result in exception)

    
> Invocation of any container lifecycle event method at runtime should result in exception
> ----------------------------------------------------------------------------------------
>
>                 Key: CDI-425
>                 URL: https://issues.jboss.org/browse/CDI-425
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.Final
>            Reporter: Martin Kouba
>
> At runtime (after AfterDeploymentValidation event is fired) invocation of container lifecycle event methods should be explicitly forbidden and result in exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Fri Mar  7 08:56:58 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 7 Mar 2014 14:56:58 +0100
Subject: [cdi-dev] Forward CDI 2.0
Message-ID: <0DE89AB2-3F78-4AA5-AFDA-A0D5FEC9F11E@sabot-durand.net>

Hi all,

For your information (and comment) I posted my wish list for CDI 2.0. You can read it here : 

http://www.dzone.com/links/forward_cdi_20.html

Thanks

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

From yann.blazart at bycode.fr  Fri Mar  7 18:08:07 2014
From: yann.blazart at bycode.fr (Yann Blazart)
Date: Sat, 8 Mar 2014 00:08:07 +0100
Subject: [cdi-dev] New on the mailing list and wish to help !
Message-ID: <CAGzuhA5P1T9SFgtQMr_W83Cb4-3GgY-s_2CnHoJ9=u9xL6M8Dw@mail.gmail.com>

Hi everybody !

I'm Yann Blazart.

First please apologize my bad english, I'm french. I will try to write as
correctly as possible.

So I'm a French Java  EE Architect with 15 years of experience, and more of
that I'm a Java EE, EJB, and CDI evangelist (fullstack in facts) !

Since some time now, I'm writing methodology and frameworks to help my
developers teams to work efficiently and easily with Java  EE, and I really
appreciate this technology.

But now I wish to give some time and help the cdi-sepc community.

Are you agree ?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140308/ab7d43a0/attachment.html 

From issues at jboss.org  Sat Mar  8 05:08:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 8 Mar 2014 05:08:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-380) Clarify SessionScoped
In-Reply-To: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494577.1371584170000.13659.1394273313551@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-380:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Clarify SessionScoped
> ---------------------
>
>                 Key: CDI-380
>                 URL: https://issues.jboss.org/browse/CDI-380
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The javadocs say:
> The request context is destroyed:
>    - at the end of the servlet request, after the service() method, all
>      doFilter() methods, and all requestDestroyed() and onComplete()
>      notifications return,
> ...
> The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListeners have been called, and at the very end of any request in
> which invalidate() was called, after all filters and ServletRequestListeners
> have been called.
> Those definitions are different.
> The session context rule seems to be a combination of "or" items that
> include some "and" items.  It's difficult to parse.  It would be clearer
> if it was written as a list.  And, like request scoped, it would be clearer
> if it described when the session scope/context is created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar  8 05:08:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 8 Mar 2014 05:08:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.13661.1394273313652@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-280:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar  8 05:14:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 8 Mar 2014 05:14:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-381) Additional implementations of
 Request Context
In-Reply-To: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494579.1371584449000.13666.1394273673258@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-381:
----------------------------------------

    Assignee:     (was: Antoine Sabot-Durand)

    
> Additional implementations of Request Context
> ---------------------------------------------
>
>                 Key: CDI-381
>                 URL: https://issues.jboss.org/browse/CDI-381
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Priority: Minor
>              Labels: CDI_api_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that?  The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes.  It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar  8 05:14:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 8 Mar 2014 05:14:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-380) Clarify SessionScoped
In-Reply-To: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494577.1371584170000.13668.1394273673389@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-380:
-------------------------------------

    Assignee:     (was: Antoine Sabot-Durand)

    
> Clarify SessionScoped
> ---------------------
>
>                 Key: CDI-380
>                 URL: https://issues.jboss.org/browse/CDI-380
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Priority: Minor
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The javadocs say:
> The request context is destroyed:
>    - at the end of the servlet request, after the service() method, all
>      doFilter() methods, and all requestDestroyed() and onComplete()
>      notifications return,
> ...
> The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListeners have been called, and at the very end of any request in
> which invalidate() was called, after all filters and ServletRequestListeners
> have been called.
> Those definitions are different.
> The session context rule seems to be a combination of "or" items that
> include some "and" items.  It's difficult to parse.  It would be clearer
> if it was written as a list.  And, like request scoped, it would be clearer
> if it described when the session scope/context is created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Sat Mar  8 05:21:16 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 8 Mar 2014 11:21:16 +0100
Subject: [cdi-dev] New on the mailing list and wish to help !
In-Reply-To: <CAGzuhA5P1T9SFgtQMr_W83Cb4-3GgY-s_2CnHoJ9=u9xL6M8Dw@mail.gmail.com>
References: <CAGzuhA5P1T9SFgtQMr_W83Cb4-3GgY-s_2CnHoJ9=u9xL6M8Dw@mail.gmail.com>
Message-ID: <3510817E-D770-4C13-A5FA-88014BFA94BF@sabot-durand.net>

Hi Yann,

And welcome.
Your mail make me think we really should provide a ? getting started ? section in the site for people that want to get involve but don?t know where to begin.

Having CDI advanced users in the spec is a good thing since they have more ? field ? feedback than most of us.

So, your help is off course most welcome. Right now we are working on CDI 1.2 (a maintenance release of CDI 1.1). This release is mainly about clarifications and bug correction. Nothing very fancy but it?s an easy way to start if you want to help on CDI 2.0 as well.

If you want to give some Help on our current work. What you can do is :

- Create an account on our Jira server (issues.jboos.org). You can use your github account now to do so
- Look for the pending tickets not yet assigned for 1.2 : https://issues.jboss.org/browse/CDI-398?filter=12320805 and choose the one you feel the more comfortable with
- Don?t hesitate to discuss on the ticket or here if you need clarification.
- When ready ask to be assigned to the ticket
- On Github Fork : https://github.com/cdi-spec/cdi
- Make the modification (time to learn AsciiDoc if it?s related to the spec)
- Send PR

Other possible tasks :

-There are open ticket that needs more discussion before being assigned, you can check them and give your input if you have one : https://issues.jboss.org/browse/CDI-411?filter=12321017
- There are PR to review as well if you want to give your advice on them, here : https://github.com/cdi-spec/cdi/pulls
- Some of the 1.2 changes will have impact on TCK or Impl (that?s why it?s CDI 1.2 and not 1.1.1). I?ll let Martin Kouba and Jozef Hartinger tell if they need help on these
- If you feel like writing doc I have work pending on the website about putting a CDI tutorial online (taken from Weld doc)

That?s all that come to my mind right now?

If you?re available we have meeting on IRC (channel #jsr346 on freenode) each monday at 17:00 GMT (18:00 CET)

Welcome onboard Yann,


Antoine

 


Le 8 mars 2014 ? 00:08, Yann Blazart <yann.blazart at bycode.fr> a ?crit :

> Hi everybody ! 
> 
> I'm Yann Blazart.
> 
> First please apologize my bad english, I'm french. I will try to write as correctly as possible.
> 
> So I'm a French Java  EE Architect with 15 years of experience, and more of that I'm a Java EE, EJB, and CDI evangelist (fullstack in facts) ! 
> 
> Since some time now, I'm writing methodology and frameworks to help my developers teams to work efficiently and easily with Java  EE, and I really appreciate this technology.
> 
> But now I wish to give some time and help the cdi-sepc community. 
> 
> Are you agree ?
> 
> Thanks.
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

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

From issues at jboss.org  Sat Mar  8 05:48:33 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 8 Mar 2014 05:48:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.13685.1394275713573@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-280:
-----------------------------------

The terms used and defined in CDI 1.0 shall not be changed imo.

Bean Class:  that's ok and the same as you meant.
Contextual Instance: The 'singleton' instance  created by the Bean#create() and stored in the Context
Contextual Reference: The NormalScope proxy for the Contextual Reference. Not to confuse with the interceptor/decorator proxy which may also exist for non-normalscoped beans.
I don't fully agree with Martin regarding 'required type'. This only covers the java.lang.reflect.Type aspect imo but does not cover the qualifiers, right? Or does it?
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar  8 06:19:33 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 8 Mar 2014 06:19:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.13705.1394277573220@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-280:
-----------------------------------

To stress the importance of the 'Contextual Reference' term: This is also the reason why the methods of the BeanManager are named #getReference() ...
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar  8 11:46:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 8 Mar 2014 11:46:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.13751.1394297193214@jira02.app.mwc.hst.phx2.redhat.com>


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

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

[~struberg],  as I said before I'm not fan of the "contextual" name and I prefer "bean" (Bean instance, Bean Reference) since it's the usage in technical post and books on CDI and other IoC frameworks. My goal here is to have the spec read by end users as well as implementors. IMO, There's enough complex concepts to catch in the spec (remember the discussion on Observer Resolution) to add new hermetic terms were convention brought ones. There are 100% chance that usage keep the simpler one and that the spec would be a bit harder to be read.

I'm afraid we won't come on an agreement on time to reprocess all these terms in the Maintenance Release time frame
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar  8 12:19:33 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 8 Mar 2014 12:19:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.13756.1394299173232@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-280:
-----------------------------------

I'm strongly -1 to re-coining the term Bean inside the spec. This terminus tecnicus is already used in the CDI area for the Metadata. This is why BeanManager#getBeans() is named that way and also the name of our Bean<T> class.
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar  8 12:37:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 8 Mar 2014 12:37:33 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.13759.1394300253198@jira02.app.mwc.hst.phx2.redhat.com>


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

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

As mentioned in one of my previous comment the term "Bean Metadata" is already widely used in the spec in 5.5.8 for this concept. Other places in chapter 11 talk about "the Bean Interface". I don't understand your point :  are suggesting replacing the term "Bean Metadata" for "Bean" ?
On the orher hand the term "Bean" is already used in a lot of place (like 2.2) and nowhere it point to Bean<T>.

So again as I stated twice in this ticket, if we agree on the terms "Bean Class" and "Bean Metadata" (which are in use in the spec) and want to be consistent "Bean Instance" and "Bean Reference" makes sense. I agree that we should avoid using the lonely term "Bean" in the spec but should keep it's usage for the day-to-day work of our users to abbreviate "Bean Instance" or "Bean reference".
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 03:53:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 10 Mar 2014 03:53:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-425) Invocation of any container
 lifecycle event method at runtime should result in exception
In-Reply-To: <JIRA.12534295.1394118564000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534295.1394118564000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534295.1394118564000.58.1394437990686@jira02.app.mwc.hst.phx2.redhat.com>


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

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

This means we should enrich Javadoc for all initialization event. Do you propose a modification in the spec as well ?
                
> Invocation of any container lifecycle event method at runtime should result in exception
> ----------------------------------------------------------------------------------------
>
>                 Key: CDI-425
>                 URL: https://issues.jboss.org/browse/CDI-425
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.1.Final
>            Reporter: Martin Kouba
>
> At runtime (after AfterDeploymentValidation event is fired) invocation of container lifecycle event methods should be explicitly forbidden and result in exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From pmuir at redhat.com  Mon Mar 10 07:25:51 2014
From: pmuir at redhat.com (Pete Muir)
Date: Mon, 10 Mar 2014 11:25:51 +0000
Subject: [cdi-dev] Scope of what bean archives an extension applies to
In-Reply-To: <859F918F-94BE-4891-BFE5-D5B31756B00F@sabot-durand.net>
References: <CAOqetn_YrQU4QsPNDDjWoscoWCRJna61pqyu5ZvEaRPtQzRw4g@mail.gmail.com>
	<859F918F-94BE-4891-BFE5-D5B31756B00F@sabot-durand.net>
Message-ID: <B5ECC0D9-F629-4B86-8EC8-79F5C4A7C92A@redhat.com>

The only real reference is 11.5

"The container instantiates a single instance of each extension at the beginning of the application initialization process and maintains a reference to it until the application shuts down. The container delivers event notifications to this instance by calling its observer methods.

For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier at Default, supporting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces.?

This is a known place in the spec where more detail should be provided and there should be a (number of) open CDI issue(s).

On 24 Feb 2014, at 10:09, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:

> Hi John,
> 
> Yes it doesn?t seem to be explicitly written (I?m still looking) but reading at the beginning of chapter 12, it?s implicit that there?s one container that do one bean discovery and fire on set of events for type discovered. So IMO, it's implicit that extensions are not limited to their current archive and have the same ? visibility ? level than the CDI container : i.e. the current application.
> This said, it couldn?t hurt to write it explicitly.
> 
> Antoine
> 
> Le 22 f?vr. 2014 ? 21:51, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
>> Hi all,
>> 
>> Quick question.  This is mostly from playing around with Weld SE
>> 2.1.2, so I'm not sure if my question is going to be Weld SE specific
>> or be generally applied.
>> 
>> Looking through the spec, I did not see any obvious indications of
>> this.  What is the scope of the application of an Extension class?
>> Suppose I had a JAR file that had
>> META-INF/services/javax.enterprise.inject.spi.Extension with the
>> contents of some extension class.  Should the application of that
>> extension class apply to all JARs within the same classpath?  If that
>> extension were listed in a WAR file, would it apply to the WAR and all
>> JAR modules?
>> 
>> John
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev



From issues at jboss.org  Mon Mar 10 07:29:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Mon, 10 Mar 2014 07:29:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.648.1394450950846@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-392:
-------------------------------

Do we have an updated version of the change?
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 07:39:11 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Mon, 10 Mar 2014 07:39:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.684.1394451551205@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-408:
-------------------------------

[~jason.greene], [~swd847] can you comment on any performance concerns with [~antoinesabot-durand] summary of options?
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 08:03:10 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Mon, 10 Mar 2014 08:03:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.731.1394452990914@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene commented on CDI-408:
----------------------------------

It's not a problem to pick up on annotations at the method level, since that information is already analyzed. So I would go with option 1 IMO.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 09:21:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 10 Mar 2014 09:21:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.1158.1394457671188@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Since [mine|#comment-12947802]? No

Now we have this question [~pmuir] about the Javadoc and the presence of

{quote}
The container is permitted to define a non-portable mode in which getBeans(Type, Annotation...) may be called from an observer of the AfterBeanDiscovery event.
{quote}

There must be a reason to create this complexity but I really didn't find it...
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 09:49:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 10 Mar 2014 09:49:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.1472.1394459352126@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-280:
-------------------------------------

    Labels: CDI_api_chge CDI_spec_chge  (was: CDI_api_chge CDI_spec_chge Ready_to_fix)

    
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 10:05:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 10 Mar 2014 10:05:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of
 @RequestScoped and @ApplicationScoped in section 2.4.1
In-Reply-To: <JIRA.12503242.1381927095000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503242.1381927095000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503242.1381927095000.1590.1394460311845@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Reproducing IRC discussion between [~pmuir] (pmuir) and [~antoinesabot-durand] (asd) about this ticket and corresponding PR

{code}
<+pmuir> asd: for https://github.com/cdi-spec/cdi/pull/204
<+pmuir> I think the new wording is too verbose and wooly
<+asd> +1. Your input as an english native speaker would be very appreciated here
<+pmuir> I wonder if we can't say something like (i.e. to paraphrase) "The container must provide an implementation of the @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in [builtin_contexts] representing the standard scopes defined by the Java Servlets specification."
<+pmuir> we would need to reword the second bullet as well, to keep the definitions consistent
<+asd> with that you remove the idea that these context are not restrict to servlet scopes IMO
<+asd> the main idea should be "it's like scope in servlet spec but it could be more"
<+asd> the main issue with this is nowhere in the spec we indicate how a third party spec could extend @RequestScoped...
<+pmuir> that I think we should add to 6.2
<+pmuir> "A context object may be defined for any of the built-in scopes"
<+pmuir> agreed?
<+asd> ok
{code}

So the reword should be simplified and a new mention should be put regarding built-in scopes extension.
I'm modifying the PR with this new approach.
                
> Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1
> --------------------------------------------------------------------------------
>
>                 Key: CDI-405
>                 URL: https://issues.jboss.org/browse/CDI-405
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From john.d.ament at gmail.com  Mon Mar 10 10:17:18 2014
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 10 Mar 2014 10:17:18 -0400
Subject: [cdi-dev] Scope of what bean archives an extension applies to
In-Reply-To: <B5ECC0D9-F629-4B86-8EC8-79F5C4A7C92A@redhat.com>
References: <CAOqetn_YrQU4QsPNDDjWoscoWCRJna61pqyu5ZvEaRPtQzRw4g@mail.gmail.com>
	<859F918F-94BE-4891-BFE5-D5B31756B00F@sabot-durand.net>
	<B5ECC0D9-F629-4B86-8EC8-79F5C4A7C92A@redhat.com>
Message-ID: <CAOqetn_ZSTe4Fivyo4_aL=3rXJdqrgakJYSLJmVOWcFR4TE+KA@mail.gmail.com>

So, if I'm getting you guys right.

- An extension applies to the entire application.
- An extension should apply to the entire application even if it has
been defined within a bean archive that is within the application
(e.g. a JAR inside a WAR).

I'm happy to create an issue (if none exists) and reword the spec to
clarify this in 11.5, if it makes sense.

- John

On Mon, Mar 10, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
> The only real reference is 11.5
>
> "The container instantiates a single instance of each extension at the beginning of the application initialization process and maintains a reference to it until the application shuts down. The container delivers event notifications to this instance by calling its observer methods.
>
> For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier at Default, supporting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces."
>
> This is a known place in the spec where more detail should be provided and there should be a (number of) open CDI issue(s).
>
> On 24 Feb 2014, at 10:09, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>
>> Hi John,
>>
>> Yes it doesn't seem to be explicitly written (I'm still looking) but reading at the beginning of chapter 12, it's implicit that there's one container that do one bean discovery and fire on set of events for type discovered. So IMO, it's implicit that extensions are not limited to their current archive and have the same << visibility >> level than the CDI container : i.e. the current application.
>> This said, it couldn't hurt to write it explicitly.
>>
>> Antoine
>>
>> Le 22 f?vr. 2014 ? 21:51, John D. Ament <john.d.ament at gmail.com> a ?crit :
>>
>>> Hi all,
>>>
>>> Quick question.  This is mostly from playing around with Weld SE
>>> 2.1.2, so I'm not sure if my question is going to be Weld SE specific
>>> or be generally applied.
>>>
>>> Looking through the spec, I did not see any obvious indications of
>>> this.  What is the scope of the application of an Extension class?
>>> Suppose I had a JAR file that had
>>> META-INF/services/javax.enterprise.inject.spi.Extension with the
>>> contents of some extension class.  Should the application of that
>>> extension class apply to all JARs within the same classpath?  If that
>>> extension were listed in a WAR file, would it apply to the WAR and all
>>> JAR modules?
>>>
>>> John
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>


From issues at jboss.org  Mon Mar 10 10:21:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 10 Mar 2014 10:21:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.1655.1394461271048@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Thanks [~jason.greene] and [~pmuir] .
That means that we should enhanced the list of _bean defining annotations_ by adding {{@Observes}} and {{@Produces}} to them and introduce the fact that _bean defining annotations_ can be *inside* a class.
Is it ok for everyone?

And last question what about {{@Observes(notifyObserver = Reception.IF_EXISTS)}}?
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 12:47:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 10 Mar 2014 12:47:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.2359.1394470030773@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand edited comment on CDI-408 at 3/10/14 12:46 PM:
--------------------------------------------------------------------

Thanks [~jason.greene] and [~pmuir] .
That means that we should enhanced the list of _bean defining annotations_ by adding {{@Observes}} and {{@Produces}} to them and introduce the fact that _bean defining annotations_ can be *inside* a class.
Is it ok for everyone?
                
      was (Author: antoinesabot-durand):
    Thanks [~jason.greene] and [~pmuir] .
That means that we should enhanced the list of _bean defining annotations_ by adding {{@Observes}} and {{@Produces}} to them and introduce the fact that _bean defining annotations_ can be *inside* a class.
Is it ok for everyone?

And last question what about {{@Observes(notifyObserver = Reception.IF_EXISTS)}}?
                  
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 13:17:10 2014
From: issues at jboss.org (John Ament (JIRA))
Date: Mon, 10 Mar 2014 13:17:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-426) Clarify the applied scope of an
	extension.
In-Reply-To: <JIRA.12534592.1394471766715@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534592.1394471766715@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534592.1394471766715.2479.1394471830941@jira02.app.mwc.hst.phx2.redhat.com>

John Ament created CDI-426:
------------------------------

             Summary: Clarify the applied scope of an extension.
                 Key: CDI-426
                 URL: https://issues.jboss.org/browse/CDI-426
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Portable Extensions
    Affects Versions: 1.1.PFD
            Reporter: John Ament


Clarify that a portable extension is applied to an entire application, rather than inferring that it's scope is application scoped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 10 13:59:13 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 10 Mar 2014 13:59:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.2602.1394474353223@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-408:
-----------------------------------

extending the bean defining annotations with annotations from the class itself is no problem. But having to go into the class and define producer methods or fields, etc as bean defining would be much more work. 

You should also think about what happens with a producer method which is contained in a super class. Does that mean we should pick up the child class as dependent scoped?

Imo we should have a few very clear rules. Not too many rules and not too complex ones. If a user expects a class to get picked up is only a matter the learning curve ;)
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 11 01:45:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 11 Mar 2014 01:45:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.3822.1394516711701@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Honestly I don't understand [~struberg]. Today in CDI 1.0 and in CDI 1.1 with {{bean-discovery-mode=all}} mode we do these deep class analysis. So the code is already there in implementations. Ok, it probably has to be adapted but it don't see where is the "much more work" in term of dev.
Solution at the impl level are multiple :

 * Start as if we where in {{bean-discovery-mode=all}} and use the same mechanism that reject non eligible class (after finding no default constructor for instance) or that {{@Vetoed}} it, if it doesn't contain bean defining annotation
 * Use annotation processing to decide at compile time.

My understanding of the {{annotated}} bean discovery mode is not about optimization, it's about CDI automatic activation. If it's optimized it's better but the first goal is to provide CDI implicitly. For me it's not important if the {{annotated}} bean discovery mode take the same amount of time at boot time than {{all}} bean-discovery-mode and that's the only risk we take here in term of "much more work".
IMO The real question is "does this feature is interesting for the end user ?" and then "how much does it costs in terms of dev and perf ?".
In this particular case I won't say the feature is awesome but the lack of it is very not user friendly.
We have zillion forum post and stack exchange "bug" out there about CDI 1.0 users forgetting {{beans.xml}} in their app. Now that we provide the mean in CDI 1.1+ to get rid of this file I really think we should do it as complete as possible.

Regarding the producer method in superclass, I'm not sure to totally understand your use case. Can you give an example ?
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 11 04:03:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 11 Mar 2014 04:03:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.3896.1394524990778@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-392:
-------------------------------------

Kind of backwards compatibility with CDI 1.0 where there were no rules of when a BM method may be called.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 11 04:33:11 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 11 Mar 2014 04:33:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.3929.1394526791460@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-408:
-------------------------------------

{quote}You should also think about what happens with a producer method which is contained in a super class.{quote}
I think that if we go with option 1 we should only detect classes that declare an observer/producer method. This would be consistent with how we treat bean defining annotations now where we require them to be declared on a class (if they are inherited that is not enough).



                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 11 04:47:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 11 Mar 2014 04:47:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.3984.1394527630703@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand edited comment on CDI-408 at 3/11/14 4:46 AM:
-------------------------------------------------------------------

Honestly I don't understand [~struberg]. Today in CDI 1.0 and in CDI 1.1 with {{bean-discovery-mode=all}} mode we do these deep class analysis. So the code is already there in implementations. Ok, it probably has to be adapted but I don't see where is the "much more work" in term of dev.
Solution at the impl level are multiple :

 * Start as if we where in {{bean-discovery-mode=all}} and use the same mechanism that reject non eligible class (after finding no default constructor for instance) or that {{@Vetoed}} it, if it doesn't contain bean defining annotation
 * Use annotation processing to decide at compile time.

My understanding of the {{annotated}} bean discovery mode is not about optimization, it's about CDI automatic activation. If it's optimized it's better but the first goal is to provide CDI implicitly. For me it's not important if the {{annotated}} bean discovery mode take the same amount of time at boot time than {{all}} bean-discovery-mode and that's the only risk we take here in term of "much more work".
IMO The real question is "does this feature is interesting for the end user ?" and then "how much does it costs in terms of dev and perf ?".
In this particular case I won't say the feature is awesome but the lack of it is very not user friendly.
We have zillion forum post and stack exchange "bug" out there about CDI 1.0 users forgetting {{beans.xml}} in their app. Now that we provide the mean in CDI 1.1+ to get rid of this file I really think we should do it as complete as possible.

Regarding the producer method in superclass, I'm not sure to totally understand your use case. Can you give an example ?
                
      was (Author: antoinesabot-durand):
    Honestly I don't understand [~struberg]. Today in CDI 1.0 and in CDI 1.1 with {{bean-discovery-mode=all}} mode we do these deep class analysis. So the code is already there in implementations. Ok, it probably has to be adapted but it don't see where is the "much more work" in term of dev.
Solution at the impl level are multiple :

 * Start as if we where in {{bean-discovery-mode=all}} and use the same mechanism that reject non eligible class (after finding no default constructor for instance) or that {{@Vetoed}} it, if it doesn't contain bean defining annotation
 * Use annotation processing to decide at compile time.

My understanding of the {{annotated}} bean discovery mode is not about optimization, it's about CDI automatic activation. If it's optimized it's better but the first goal is to provide CDI implicitly. For me it's not important if the {{annotated}} bean discovery mode take the same amount of time at boot time than {{all}} bean-discovery-mode and that's the only risk we take here in term of "much more work".
IMO The real question is "does this feature is interesting for the end user ?" and then "how much does it costs in terms of dev and perf ?".
In this particular case I won't say the feature is awesome but the lack of it is very not user friendly.
We have zillion forum post and stack exchange "bug" out there about CDI 1.0 users forgetting {{beans.xml}} in their app. Now that we provide the mean in CDI 1.1+ to get rid of this file I really think we should do it as complete as possible.

Regarding the producer method in superclass, I'm not sure to totally understand your use case. Can you give an example ?
                  
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From useyour.mind at gmail.com  Tue Mar 11 08:50:43 2014
From: useyour.mind at gmail.com (Luc)
Date: Tue, 11 Mar 2014 13:50:43 +0100
Subject: [cdi-dev] @New deprecation: when will be "real"
Message-ID: <CAJvqtSqxWPoJCmPtihNUwmQh7azNN48rup7-1bjY_3dvELOXLg@mail.gmail.com>

Hi!

I've been using CDI-1.0 for a long time, and one of the features used in my
project is @New qualifier.
A few weeks ago I migrated to CDI-1.1, but was principal for performance
promises than features. I didn't found anything really different (except
extensions), so you all woked relly good with the backward compatiblity :)

But today, I got to the @New section of docs, where it is told that the
annotation is deprecated.
It is planed in which release will be deleted the annotation, and its
associated functionality? Or not yet?

Thanks!
--
Lucas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140311/9bcff9b7/attachment.html 

From antoine at sabot-durand.net  Tue Mar 11 09:46:18 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 11 Mar 2014 14:46:18 +0100
Subject: [cdi-dev] @New deprecation: when will be "real"
In-Reply-To: <CAJvqtSqxWPoJCmPtihNUwmQh7azNN48rup7-1bjY_3dvELOXLg@mail.gmail.com>
References: <CAJvqtSqxWPoJCmPtihNUwmQh7azNN48rup7-1bjY_3dvELOXLg@mail.gmail.com>
Message-ID: <C6E5B7E2-9D3C-4BB2-9BA8-52E311DFB7A0@sabot-durand.net>

Hi Luc,

> I've been using CDI-1.0 for a long time, and one of the features used in my project is @New qualifier.
> A few weeks ago I migrated to CDI-1.1, but was principal for performance promises than features. I didn't found anything really different (except extensions), so you all woked relly good with the backward compatiblity :)

I can assure you that there new things in CDI 1.1 ;). Anyway thanks for the feedback, I?m sure people that worked hard on 1.1 will appreciate.

> But today, I got to the @New section of docs, where it is told that the annotation is deprecated.
> It is planed in which release will be deleted the annotation, and its associated functionality? Or not yet?

Nothing planned for @New withdrawal but you should be ready for its removal in CDI 2.0.
Anyway, it?s rather easy to with to @Dependent bean to avoid the usage of @New. And if you really need it, it?s quite easy to create tour own extension that register a the @New version of each of your beans.



Antoine Sabot-Durand
???????????????
Twitter : @antoine_sd
CDI co-spec lead & eco-system development
Agorava tech lead

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140311/b39a7c64/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140311/b39a7c64/attachment.bin 

From pmuir at redhat.com  Tue Mar 11 10:32:11 2014
From: pmuir at redhat.com (Pete Muir)
Date: Tue, 11 Mar 2014 14:32:11 +0000
Subject: [cdi-dev] @New deprecation: when will be "real"
In-Reply-To: <C6E5B7E2-9D3C-4BB2-9BA8-52E311DFB7A0@sabot-durand.net>
References: <CAJvqtSqxWPoJCmPtihNUwmQh7azNN48rup7-1bjY_3dvELOXLg@mail.gmail.com>
	<C6E5B7E2-9D3C-4BB2-9BA8-52E311DFB7A0@sabot-durand.net>
Message-ID: <9C99DAA9-8796-482C-8D63-03BDE8517838@redhat.com>

@New will never be removed, the deprecated status is just to indicate you shouldn?t use it.

On 11 Mar 2014, at 13:46, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:

> Hi Luc,
> 
>> I've been using CDI-1.0 for a long time, and one of the features used in my project is @New qualifier.
>> A few weeks ago I migrated to CDI-1.1, but was principal for performance promises than features. I didn't found anything really different (except extensions), so you all woked relly good with the backward compatiblity :)
> 
> I can assure you that there new things in CDI 1.1 ;). Anyway thanks for the feedback, I?m sure people that worked hard on 1.1 will appreciate.
> 
>> But today, I got to the @New section of docs, where it is told that the annotation is deprecated.
>> It is planed in which release will be deleted the annotation, and its associated functionality? Or not yet?
> 
> Nothing planned for @New withdrawal but you should be ready for its removal in CDI 2.0.
> Anyway, it?s rather easy to with to @Dependent bean to avoid the usage of @New. And if you really need it, it?s quite easy to create tour own extension that register a the @New version of each of your beans.
> 
> 
> 
> Antoine Sabot-Durand
> ???????????????
> Twitter : @antoine_sd
> CDI co-spec lead & eco-system development
> Agorava tech lead
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev



From issues at jboss.org  Tue Mar 11 14:21:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Tue, 11 Mar 2014 14:21:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.6678.1394562070935@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-408:
-------------------------------

I have to say that from a functional perspective I am quite ambivalent about this feature.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From pmuir at redhat.com  Tue Mar 11 14:29:10 2014
From: pmuir at redhat.com (Pete Muir)
Date: Tue, 11 Mar 2014 18:29:10 +0000
Subject: [cdi-dev] Scope of what bean archives an extension applies to
In-Reply-To: <CAOqetn_ZSTe4Fivyo4_aL=3rXJdqrgakJYSLJmVOWcFR4TE+KA@mail.gmail.com>
References: <CAOqetn_YrQU4QsPNDDjWoscoWCRJna61pqyu5ZvEaRPtQzRw4g@mail.gmail.com>
	<859F918F-94BE-4891-BFE5-D5B31756B00F@sabot-durand.net>
	<B5ECC0D9-F629-4B86-8EC8-79F5C4A7C92A@redhat.com>
	<CAOqetn_ZSTe4Fivyo4_aL=3rXJdqrgakJYSLJmVOWcFR4TE+KA@mail.gmail.com>
Message-ID: <E680A908-6C88-49D4-9407-FCE575497D4A@redhat.com>

Well, its not clear what the current behaviour should be, and it?s not clear what we want the behaviour to be in the future!

On 10 Mar 2014, at 14:17, John D. Ament <john.d.ament at gmail.com> wrote:

> So, if I'm getting you guys right.
> 
> - An extension applies to the entire application.
> - An extension should apply to the entire application even if it has
> been defined within a bean archive that is within the application
> (e.g. a JAR inside a WAR).
> 
> I'm happy to create an issue (if none exists) and reword the spec to
> clarify this in 11.5, if it makes sense.
> 
> - John
> 
> On Mon, Mar 10, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>> The only real reference is 11.5
>> 
>> "The container instantiates a single instance of each extension at the beginning of the application initialization process and maintains a reference to it until the application shuts down. The container delivers event notifications to this instance by calling its observer methods.
>> 
>> For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier at Default, supporting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces."
>> 
>> This is a known place in the spec where more detail should be provided and there should be a (number of) open CDI issue(s).
>> 
>> On 24 Feb 2014, at 10:09, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>> 
>>> Hi John,
>>> 
>>> Yes it doesn't seem to be explicitly written (I'm still looking) but reading at the beginning of chapter 12, it's implicit that there's one container that do one bean discovery and fire on set of events for type discovered. So IMO, it's implicit that extensions are not limited to their current archive and have the same << visibility >> level than the CDI container : i.e. the current application.
>>> This said, it couldn't hurt to write it explicitly.
>>> 
>>> Antoine
>>> 
>>> Le 22 f?vr. 2014 ? 21:51, John D. Ament <john.d.ament at gmail.com> a ?crit :
>>> 
>>>> Hi all,
>>>> 
>>>> Quick question.  This is mostly from playing around with Weld SE
>>>> 2.1.2, so I'm not sure if my question is going to be Weld SE specific
>>>> or be generally applied.
>>>> 
>>>> Looking through the spec, I did not see any obvious indications of
>>>> this.  What is the scope of the application of an Extension class?
>>>> Suppose I had a JAR file that had
>>>> META-INF/services/javax.enterprise.inject.spi.Extension with the
>>>> contents of some extension class.  Should the application of that
>>>> extension class apply to all JARs within the same classpath?  If that
>>>> extension were listed in a WAR file, would it apply to the WAR and all
>>>> JAR modules?
>>>> 
>>>> John
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 



From issues at jboss.org  Tue Mar 11 17:23:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 11 Mar 2014 17:23:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.7569.1394572992814@jira02.app.mwc.hst.phx2.redhat.com>


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

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

[~pmuir] I'm not a big fan ever but in fact I'm not a big fan of the annotated mode and this is linked to it. That said I really think we should try to avoid option 3 IMO. Or at least request that the impl logs the list of ignored class in annotated mode.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jharting at redhat.com  Wed Mar 12 05:08:56 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 12 Mar 2014 10:08:56 +0100
Subject: [cdi-dev] Bean defining annotations
Message-ID: <53202428.8050500@redhat.com>

Hi all,

the CDI spec change, which adds @Interceptor, @Decorator and stereotypes 
to the set of bean defining annotations, was merged. This made me think 
whether this approach where we add annotations based on demand is the 
right one. Instead, I think we should review all the annotations defined 
in the CDI API and evaluate if it makes to have them as bean defining 
annotations. I think that this would yield more consistent and less 
ad-hoc result.

Two candidates that come to mind are @Alternative and @Specializes.

WDYT?

Jozef

From issues at jboss.org  Wed Mar 12 05:17:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Wed, 12 Mar 2014 05:17:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.8129.1394615830942@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-408:
-------------------------------

I guess that (2) is possible...
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 05:21:11 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 12 Mar 2014 05:21:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.8156.1394616071240@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-408:
-------------------------------------

If we add any requirements on what is logged by the application server it should have a form of a recommendation instead of a strict requirement IMO because:
1) it cannot be tested by TCK anyway
2) AFAIK there is no precedence for this in EE. I have only seen recommendations on logging in EE specs.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 05:27:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 05:27:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.8172.1394616431089@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Sure (2) will have less side effect but at the same time it's a waste to do this analysis work and not implement (1) ;). Ambivalent was your word [~pmuir] :-D.
Perhaps we should vote here... 
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 05:39:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 05:39:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.8215.1394617151363@jira02.app.mwc.hst.phx2.redhat.com>


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

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

+1 [~jharting]. I was only thinking aloud. 
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Wed Mar 12 05:46:23 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 12 Mar 2014 10:46:23 +0100
Subject: [cdi-dev] Bean defining annotations
In-Reply-To: <F453CF12-51FF-4CDB-A833-357425C3A980@sabot-durand.net>
References: <53202428.8050500@redhat.com>
	<F453CF12-51FF-4CDB-A833-357425C3A980@sabot-durand.net>
Message-ID: <3DDBEBFD-EAAF-47B1-85EA-8C172035C53B@sabot-durand.net>


I agree Jozef. We started on this re-definifition of bean defining annotations sets to correct CDI-377, but if we can check all class annotation (and perhaps more depending of CDI-408 resolution) in CDI, it would be a cleaner job. Can you create the ticket for that ?

Antoine


> Le 12 mars 2014 ? 10:08, Jozef Hartinger <jharting at redhat.com> a ?crit :
> 
>> Hi all,
>> 
>> the CDI spec change, which adds @Interceptor, @Decorator and stereotypes 
>> to the set of bean defining annotations, was merged. This made me think 
>> whether this approach where we add annotations based on demand is the 
>> right one. Instead, I think we should review all the annotations defined 
>> in the CDI API and evaluate if it makes to have them as bean defining 
>> annotations. I think that this would yield more consistent and less 
>> ad-hoc result.
>> 
>> Two candidates that come to mind are @Alternative and @Specializes.
>> 
>> WDYT?
>> 
>> Jozef
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 

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

From issues at jboss.org  Wed Mar 12 05:47:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 12 Mar 2014 05:47:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-427) Review all annotations for
 inclusion to bean defining annotations
In-Reply-To: <JIRA.12534745.1394617589207@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534745.1394617589207@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534745.1394617589207.8240.1394617630722@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created CDI-427:
-----------------------------------

             Summary: Review all annotations for inclusion to bean defining annotations
                 Key: CDI-427
                 URL: https://issues.jboss.org/browse/CDI-427
             Project: CDI Specification Issues
          Issue Type: Feature Request
    Affects Versions: 1.1.FD
            Reporter: Jozef Hartinger
             Fix For: 1.2 Proposed


The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result.

Two candidates that come to mind are @Alternative and @Specializes.

This issue depends on the resolution of CDI-408

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jharting at redhat.com  Wed Mar 12 05:50:19 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 12 Mar 2014 10:50:19 +0100
Subject: [cdi-dev] Bean defining annotations
In-Reply-To: <3DDBEBFD-EAAF-47B1-85EA-8C172035C53B@sabot-durand.net>
References: <53202428.8050500@redhat.com>
	<F453CF12-51FF-4CDB-A833-357425C3A980@sabot-durand.net>
	<3DDBEBFD-EAAF-47B1-85EA-8C172035C53B@sabot-durand.net>
Message-ID: <53202DDB.6060707@redhat.com>

https://issues.jboss.org/browse/CDI-427

On 03/12/2014 10:46 AM, Antoine Sabot-Durand wrote:
> I agree Jozef. We started on this re-definifition of bean defining annotations sets to correct CDI-377, but if we can check all class annotation (and perhaps more depending of CDI-408 resolution) in CDI, it would be a cleaner job. Can you create the ticket for that ?
>
> Antoine
>
>
>> Le 12 mars 2014 ? 10:08, Jozef Hartinger <jharting at redhat.com> a ?crit :
>>
>>> Hi all,
>>>
>>> the CDI spec change, which adds @Interceptor, @Decorator and stereotypes
>>> to the set of bean defining annotations, was merged. This made me think
>>> whether this approach where we add annotations based on demand is the
>>> right one. Instead, I think we should review all the annotations defined
>>> in the CDI API and evaluate if it makes to have them as bean defining
>>> annotations. I think that this would yield more consistent and less
>>> ad-hoc result.
>>>
>>> Two candidates that come to mind are @Alternative and @Specializes.
>>>
>>> WDYT?
>>>
>>> Jozef
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev


From issues at jboss.org  Wed Mar 12 06:23:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 06:23:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.8340.1394619791185@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand edited comment on CDI-392 at 3/12/14 6:21 AM:
-------------------------------------------------------------------

Moved PR to CDI official repo
https://github.com/cdi-spec/cdi/pull/215
                
      was (Author: antoinesabot-durand):
    Moved PR to CDI official repo.
                  
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 06:35:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Wed, 12 Mar 2014 06:35:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.8394.1394620510985@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-408:
-------------------------------

Ok, I vote for option 3.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 06:39:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 06:39:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.8405.1394620751120@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Option 1 for me
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 06:43:10 2014
From: issues at jboss.org (Jens Schumann (JIRA))
Date: Wed, 12 Mar 2014 06:43:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.8413.1394620990731@jira02.app.mwc.hst.phx2.redhat.com>


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

Jens Schumann commented on CDI-408:
-----------------------------------

(Even though my vote will not count) I vote for option 1 but we will be happy with option 3 if documentation takes place in MR 1.2.

Just in case we go with option 3 I will create a new ticket containing option 1 for CDI 2.0;).
Thanks for the discussion.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 06:51:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Wed, 12 Mar 2014 06:51:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.8458.1394621470873@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-280:
-------------------------------

I don't want us to start redefining all the terms. That will be super-confusing for everyone.

I think it would be more useful to compile a complete list of all terms used, with references, and see if there is incorrect usage, or two terms referencing the same thing. If we have two terms used for exactly the same thing, then we should choose one.
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Wed Mar 12 07:04:28 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 12 Mar 2014 12:04:28 +0100
Subject: [cdi-dev] Vote on CDI-408 bean-discovery-mode="annotated" and
	Producers/Observers in @Dependent beans
Message-ID: <DF092BFB-DA80-408A-822A-CF73750D8B92@sabot-durand.net>

Hi all,

Vote is open between the following options :

1) Add to the bean defining annotation list @Produces and @Observes. That will add to the list annotations inside a class.
2) Detect @Produces and @Observes in class that don't have bean defining annotation and warn the user at boot time. It seems to be a work very close to previous point in term of scanning.
3) Do nothing in the container and only document in spec the fact that in annotated mode these will be ignored silently.

Vote on the JIRA ticket please.

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

From issues at jboss.org  Wed Mar 12 10:45:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 10:45:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-388) Session bean specialization
 example is not valid
In-Reply-To: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496123.1373466177000.9140.1394635511581@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-388:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Session bean specialization example is not valid
> ------------------------------------------------
>
>                 Key: CDI-388
>                 URL: https://issues.jboss.org/browse/CDI-388
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> {code}
> @Stateless
> public class LoginActionBean implements LoginAction { ... }
> @Stateless @Mock @Specializes
> public class MockLoginActionBean extends LoginActionBean { ... }
> {code}
> {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses").
> The spec also states (4.3.1 Direct and indirect specialization):
> {quote}
> Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
> {quote}
> So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 10:49:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 10:49:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-388) Session bean specialization
 example is not valid
In-Reply-To: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496123.1373466177000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496123.1373466177000.9161.1394635750690@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-388 started by Antoine Sabot-Durand.

> Session bean specialization example is not valid
> ------------------------------------------------
>
>                 Key: CDI-388
>                 URL: https://issues.jboss.org/browse/CDI-388
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> {code}
> @Stateless
> public class LoginActionBean implements LoginAction { ... }
> @Stateless @Mock @Specializes
> public class MockLoginActionBean extends LoginActionBean { ... }
> {code}
> {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses").
> The spec also states (4.3.1 Direct and indirect specialization):
> {quote}
> Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
> {quote}
> So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 11:19:10 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Wed, 12 Mar 2014 11:19:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.9258.1394637550779@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-408:
-----------------------------------

+1 for option 3. Simply because option 1 would need us to not only look inside a class for annotations, but we would *also* need to look up all fields and methods in the super-classes!
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 11:23:11 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Wed, 12 Mar 2014 11:23:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.9276.1394637791228@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-392:
-----------------------------------

[~jharting] I'm not sure we need the backward compatibility in this case. We just prevent something which creates a random behaviour because the result of e.g. getBeans(Type) during bootstrap depends only on the order in which the classes get scanned. And this is absolutely random.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 11:31:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 11:31:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.9306.1394638270748@jira02.app.mwc.hst.phx2.redhat.com>


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

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

I agree with [~struberg]. I've experienced this bug in CDI 1.0, I'd prefer to have an exception. Unless there's another reason I think we should get rid of this "container is permitted to define a non-portable mode..." mention
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 11:31:11 2014
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 12 Mar 2014 11:31:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.9318.1394638271314@jira02.app.mwc.hst.phx2.redhat.com>


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

John Ament commented on CDI-408:
--------------------------------

I'd vote for option 2, but looks a bit too expensive so I'd vote for #3.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 11:37:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 12 Mar 2014 11:37:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.9346.1394638631114@jira02.app.mwc.hst.phx2.redhat.com>


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

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

I won't go back in terminology war. I'm the newbie here and understand my user / usage oriented pov is not widely shared ;).
Anyway, I think we're too late to produce a quality work on this. I propose we postpone this lexical dispute for 2.0 where most of the spec will more deeply reviewed. So I think we should remove this ticket from 1.2.
WDYT?
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 12:17:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Wed, 12 Mar 2014 12:17:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.9531.1394641030817@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-392:
-------------------------------

I can't honestly remember why it is there. Have you checked the commit log?
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 13:41:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 12 Mar 2014 13:41:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.9765.1394646070714@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-392:
-------------------------------------

It's there because extensions existed (and may still exist) that called these BM methods in ABD (e.g. Seam Solder).
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 13:43:11 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 12 Mar 2014 13:43:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.9771.1394646191927@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-408:
-------------------------------------

{quote}but we would also need to look up all fields and methods in the super-classes!{quote}
Why?
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 13:53:10 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Wed, 12 Mar 2014 13:53:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.9814.1394646790602@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-392:
-----------------------------------

Well, the whole wording that 'containers may provide some flag to enable a different mode' is not worth mentioning throughout the spec, because every container is free to provide different behaviour for everything - as long as it is not enabled by default!
The only thing worth mentioning is if a container _must_ provide such a mode.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 13:57:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 12 Mar 2014 13:57:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.9823.1394647030651@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-280:
-------------------------------------

+1
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 14:04:00 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Wed, 12 Mar 2014 14:04:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.9834.1394647440616@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-408:
-----------------------------------

[jharting] you have a class which has some CDI 'features'. Then you create a subclass for it. This subclass will *not* get picked up if we don't look up in the class hierarchy.

To be honest. If we start with 1. then people will complain why we cannot pickup beans as @Dependent if they have an @Inject field. There is no reason why picking @Observes and @Produces but not @Inject... So either we have a clear class-only or we go the full route imo.

                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Mar 12 17:39:11 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 12 Mar 2014 17:39:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.10879.1394660351627@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-408:
-------------------------------------

{quote}This subclass will not get picked up if we don't look up in the class hierarchy.{quote}
I find the fact that only classes that declare a bean defining annotation within their definition are picked up quite easy to grasp by application developers.

{quote}There is no reason why picking @Observes and @Produces but not @Inject... So either we have a clear class-only or we go the full route imo.{quote}
I agree that picking up based on @Produces but not on @Inject is counter-intuitive. However, we cannot go "the full route" because @Inject is not CDI-specific which means that we would end up in a situation similar to the one with @Singletons. So after all, option 3 is probably the best one.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 13 04:54:11 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 13 Mar 2014 04:54:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.11798.1394700851045@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba commented on CDI-280:
----------------------------------

+1 for postponing
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 13 05:32:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 13 Mar 2014 05:32:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-427) Review all annotations for
 inclusion to bean defining annotations
In-Reply-To: <JIRA.12534745.1394617589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534745.1394617589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534745.1394617589000.11943.1394703131144@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-427:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge  (was: )

    
> Review all annotations for inclusion to bean defining annotations
> -----------------------------------------------------------------
>
>                 Key: CDI-427
>                 URL: https://issues.jboss.org/browse/CDI-427
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result.
> Two candidates that come to mind are @Alternative and @Specializes.
> This issue depends on the resolution of CDI-408

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 13 05:32:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 13 Mar 2014 05:32:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.11939.1394703130934@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Since the behavior of these extension is not predictable on Weld 2.x, wouldn't be a better idea to remove the mention and the support (don't even know if Weld 2.x implement this non portable behavior) to make things clear ? Correct me if I'm wrong but Seam Solder is deprecated ?
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 13 05:38:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 13 Mar 2014 05:38:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.11954.1394703490787@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-392:
-------------------------------------

Weld 2.x does implement the non-portable mode.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 13 06:16:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 13 Mar 2014 06:16:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.12072.1394705772237@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ok, so what is your opinion [~jharting] about keeping or removing this non portable mode to simplify the spec?
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine.sabotdurand at gmail.com  Thu Mar 13 06:36:12 2014
From: antoine.sabotdurand at gmail.com (Antoine Sabot-Durand)
Date: Thu, 13 Mar 2014 10:36:12 +0000
Subject: [cdi-dev] Invitation: CDI 1.2 MR meeting @ Weekly from 6pm to 7pm
 on Monday from Mon Jan 27 to Mon Mar 31 (Perso)
Message-ID: <001a11c258f6a5f66104f47a8590@google.com>

You have been invited to the following event.

Title: CDI 1.2 MR meeting
Proposed agenda :
- Ready to fix review and assignation
- Discussion on other ticket
- Progess and obstacles
When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 Paris
Where: IRC #jsr346 Channel on Freenode
Calendar: Perso
Who:
     (Guest list has been hidden at organizer's request)

Event details:  
https://www.google.com/calendar/event?action=VIEW&eid=XzcwczNhZGhoOGQwazRiYTM2OHBqZWI5azZvc2pjYjlvNjRzamliOXA2Y3I0MmRoazYwcDNpZGEzNmcgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb20zMDIwMDU3OWY2Y2U5MzViOWYyZTE4YTNmNjUxZTEwNjdkZDUyZmFm&ctz=Europe/Paris&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
cdi-dev at lists.jboss.org because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/6a7bdbea/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1544 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/6a7bdbea/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1591 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/6a7bdbea/attachment-0001.bin 

From antoine.sabotdurand at gmail.com  Thu Mar 13 06:36:59 2014
From: antoine.sabotdurand at gmail.com (antoine.sabotdurand at gmail.com)
Date: Thu, 13 Mar 2014 10:36:59 +0000
Subject: [cdi-dev] Updated Invitation: CDI 1.2 MR meeting @ Weekly from 6pm
 to 7pm on Monday from Mon Jan 27 to Mon Mar 31 (Perso)
Message-ID: <047d7b3a84367313f804f47a884c@google.com>

This event has been changed.

Title: CDI 1.2 MR meeting
Proposed agenda :
- Ready to fix review and assignation
- Discussion on other ticket
- Progess and obstacles
View your event at  
http://www.google.com/calendar/event?action=VIEW&eid=XzcwczNhZGhoOGQwazRiYTM2OHBqZWI5azZvc2pjYjlvNjRzamliOXA2Y3I0MmRoazYwcDNpZGEzNmcgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb20zMDIwMDU3OWY2Y2U5MzViOWYyZTE4YTNmNjUxZTEwNjdkZDUyZmFm&ctz=Europe/Paris&hl=en.  
(changed)
When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 Paris
Where: IRC #jsr346 Channel on Freenode
Calendar: Perso
Who:
     (Guest list has been hidden at organizer's request)

Event details:  
https://www.google.com/calendar/event?action=VIEW&eid=XzcwczNhZGhoOGQwazRiYTM2OHBqZWI5azZvc2pjYjlvNjRzamliOXA2Y3I0MmRoazYwcDNpZGEzNmcgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb20zMDIwMDU3OWY2Y2U5MzViOWYyZTE4YTNmNjUxZTEwNjdkZDUyZmFm&ctz=Europe/Paris&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
cdi-dev at lists.jboss.org because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/65b07469/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1862 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/65b07469/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1913 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/65b07469/attachment-0003.bin 

From antoine.sabotdurand at gmail.com  Thu Mar 13 06:37:41 2014
From: antoine.sabotdurand at gmail.com (antoine.sabotdurand at gmail.com)
Date: Thu, 13 Mar 2014 10:37:41 +0000
Subject: [cdi-dev] Updated Invitation: CDI 1.2 MR meeting @ Weekly from 6pm
 to 7pm on Monday from Mon Jan 27 to Mon Mar 31 (Perso)
Message-ID: <047d7b3a8436faa44f04f47a8a25@google.com>

This event has been changed.

Title: CDI 1.2 MR meeting
Proposed agenda :
- Ready to fix review and assignation
- Discussion on other ticket
- Progess and obstacles
View your event at  
http://www.google.com/calendar/event?action=VIEW&eid=XzcwczNhZGhoOGQwazRiYTM2OHBqZWI5azZvc2pjYjlvNjRzamliOXA2Y3I0MmRoazYwcDNpZGEzNmcgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb20zMDIwMDU3OWY2Y2U5MzViOWYyZTE4YTNmNjUxZTEwNjdkZDUyZmFm&ctz=Europe/Paris&hl=en.
View your event at  
http://www.google.com/calendar/event?action=VIEW&eid=XzcwczNhZGhoOGQwazRiYTM2OHBqZWI5azZvc2pjYjlvNjRzamliOXA2Y3I0MmRoazYwcDNpZGEzNmcgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb20zMDIwMDU3OWY2Y2U5MzViOWYyZTE4YTNmNjUxZTEwNjdkZDUyZmFm&ctz=Europe/Paris&hl=en.  
(changed)
When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 Paris
Where: IRC #jsr346 Channel on Freenode
Calendar: Perso
Who:
     (Guest list has been hidden at organizer's request)

Event details:  
https://www.google.com/calendar/event?action=VIEW&eid=XzcwczNhZGhoOGQwazRiYTM2OHBqZWI5azZvc2pjYjlvNjRzamliOXA2Y3I0MmRoazYwcDNpZGEzNmcgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb20zMDIwMDU3OWY2Y2U5MzViOWYyZTE4YTNmNjUxZTEwNjdkZDUyZmFm&ctz=Europe/Paris&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
cdi-dev at lists.jboss.org because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/5105ac3d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 2182 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/5105ac3d/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 2238 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140313/5105ac3d/attachment-0001.bin 

From issues at jboss.org  Thu Mar 13 07:18:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Thu, 13 Mar 2014 07:18:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.12308.1394709490950@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-392:
-------------------------------

I think Mark makes a good point here.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 13 07:32:11 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Thu, 13 Mar 2014 07:32:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.12363.1394710331413@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-408:
-------------------------------

Right, I would prefer to keep bean defining annotations reasonably simple to understand.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 13 08:02:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 13 Mar 2014 08:02:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.12457.1394712130610@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-392:
-------------------------------------

I agree with Mark that the current wording of the non-portable mode does not imply anything.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From struberg at yahoo.de  Sat Mar 15 12:30:01 2014
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 15 Mar 2014 16:30:01 +0000 (GMT)
Subject: [cdi-dev] Scope of what bean archives an extension applies to
In-Reply-To: <E680A908-6C88-49D4-9407-FCE575497D4A@redhat.com>
References: <CAOqetn_YrQU4QsPNDDjWoscoWCRJna61pqyu5ZvEaRPtQzRw4g@mail.gmail.com>	<859F918F-94BE-4891-BFE5-D5B31756B00F@sabot-durand.net>	<B5ECC0D9-F629-4B86-8EC8-79F5C4A7C92A@redhat.com>	<CAOqetn_ZSTe4Fivyo4_aL=3rXJdqrgakJYSLJmVOWcFR4TE+KA@mail.gmail.com>
	<E680A908-6C88-49D4-9407-FCE575497D4A@redhat.com>
Message-ID: <1394901001.55896.YahooMailNeo@web28905.mail.ir2.yahoo.com>

look at CDI-129. Imo this is really tied to our modularisation and visibility. Think about EAR deployments. 

Imo each ClassLoader 'module' should have an own BeanManager forming a hierarchy 1:1 wich the ClassLoaders. And each BeanManager has it's own set of Extension instances.


LieGrue,
strub




On Tuesday, 11 March 2014, 19:29, Pete Muir <pmuir at redhat.com> wrote:
 
Well, its not clear what the current behaviour should be, and it?s not clear what we want the behaviour to be in the future!
>
>
>On 10 Mar 2014, at 14:17, John D. Ament <john.d.ament at gmail.com> wrote:
>
>> So, if I'm getting you guys right.
>> 
>> - An extension applies to the entire application.
>> - An extension should apply to the entire application even if it has
>> been defined within a bean archive that is within the application
>> (e.g. a JAR inside a WAR).
>> 
>> I'm happy to create an issue (if none exists) and reword the spec to
>> clarify this in 11.5, if it makes sense.
>> 
>> - John
>> 
>> On Mon, Mar 10, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>>> The only real reference is 11.5
>>> 
>>> "The container instantiates a single instance of each extension at the beginning of the application initialization process and maintains a reference to it until the application shuts down. The container delivers event notifications to this instance by calling its observer methods.
>>> 
>>> For each service provider, the container must provide a bean of scope @ApplicationScoped and qualifier at Default, supporting injection of a reference to the service provider instance. The bean types of this bean include the class of the service provider and all superclasses and interfaces."
>>> 
>>> This is a known place in the spec where more detail should be provided and there should be a (number of) open CDI issue(s).
>>> 
>>> On 24 Feb 2014, at 10:09, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>> 
>>>> Hi John,
>>>> 
>>>> Yes it doesn't seem to be explicitly written (I'm still looking) but reading at the beginning of chapter 12, it's implicit that there's one container that do one bean discovery and fire on set of events for type discovered. So IMO, it's implicit that extensions are not limited to their current archive and have the same << visibility >> level than the CDI container : i.e. the current application.
>>>> This said, it couldn't hurt to write it explicitly.
>>>> 
>>>> Antoine
>>>> 
>>>> Le 22 f?vr. 2014 ? 21:51, John D. Ament <john.d.ament at gmail.com> a ?crit :
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Quick question.? This is mostly from playing around with Weld SE
>>>>> 2.1.2, so I'm not sure if my question is going to be Weld SE specific
>>>>> or be generally applied.
>>>>> 
>>>>> Looking through the spec, I did not see any obvious indications of
>>>>> this.? What is the scope of the application of an Extension class?
>>>>> Suppose I had a JAR file that had
>>>>> META-INF/services/javax.enterprise.inject.spi.Extension with the
>>>>> contents of some extension class.? Should the application of that
>>>>> extension class apply to all JARs within the same classpath?? If that
>>>>> extension were listed in a WAR file, would it apply to the WAR and all
>>>>> JAR modules?
>>>>> 
>>>>> John
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140315/41f2e02b/attachment.html 

From pmuir at redhat.com  Sun Mar 16 13:51:15 2014
From: pmuir at redhat.com (Pete Muir)
Date: Sun, 16 Mar 2014 17:51:15 +0000
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
Message-ID: <48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>

Yeah, agreed, this is something I?ve puzzled over before.

On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:

> Hi all
> 
> 
> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you?re interested you can check the transcript [3] from 09:43.
> 
> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
> 
> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
> The only strange thing for me is that @Any seems totally useless regarding events firing
> 
> If you write : 
> @Inject Event<Payload> payLoadEvent;
> or
> @Inject @Any Event<Payload> payLoadEvent;
> 
> You?ll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
> 
> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification?
> 
> Antoine
> 
> [1] https://github.com/cdi-spec/cdi/pull/207
> [2] https://issues.jboss.org/browse/CDI-422
> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
> [4] https://github.com/antoinesd/EventsTest
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev



From john.d.ament at gmail.com  Sun Mar 16 19:56:28 2014
From: john.d.ament at gmail.com (John D. Ament)
Date: Sun, 16 Mar 2014 19:56:28 -0400
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
Message-ID: <CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>

Funny that this comes up now.  I actually hacked into my coworker's
code using an observer on any object.

I always assumed the use of @Any in the examples came from a different
version of the event observer pattern where it was a best match, not
an any match.

On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
> Yeah, agreed, this is something I've puzzled over before.
>
> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>
>> Hi all
>>
>>
>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>
>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>
>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>
>> If you write :
>> @Inject Event<Payload> payLoadEvent;
>> or
>> @Inject @Any Event<Payload> payLoadEvent;
>>
>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>
>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>
>> Antoine
>>
>> [1] https://github.com/cdi-spec/cdi/pull/207
>> [2] https://issues.jboss.org/browse/CDI-422
>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>> [4] https://github.com/antoinesd/EventsTest
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev


From antoine at sabot-durand.net  Mon Mar 17 07:19:49 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 17 Mar 2014 12:19:49 +0100
Subject: [cdi-dev] Invisible yet important modification on cdi-spec.org
Message-ID: <D38E43BE-3D83-4B2A-9658-3A8EF65438A3@sabot-durand.net>

Hi All,

I?ve been working since thursday on the website to prepare it for new contents and contributions. As I worked mainly on foundation, nothing is visible from the website. You can check the ? new ? version on staging URL [1].
Except for a few colors and pixel here and there, you should find the same site (let me know if I missed something before I switch to this new version tomorrow probably).

So what was done ? :

 - Update to Awestruct 0.5.3 (version 0.5.4 is still in Release Candidate),
 - Update to Bootstap 3.1.1 (to avoid adding content with a ? legacy ? framework).  Was a long work because a lot of things changed in templating.
 - Review Awestruct packaging to be able to generate the site and launch it more easily (it has been a hell to sort the problems out)
 - Clean all the css and ruby dependencies hell we had before.

You can check the new Readme that gives all information regarding Awestruct usage and contribution. These modification are still in their own branch (bootstrap3) to check if I didn?t missed something.

Please take a few minutes to test the new approach with Rake that is described in the README file and tell me if you encountered issues (didn?t have windows and linux box to test).

Website Next step :
 - figure out why Jira plugin does? work
 - work on the tutorial. I?ll send an other email on the subject.

Antoine



 [1] : http://www.cdi-spec.org/staging/
 [2] : https://github.com/cdi-spec/cdi-spec.org/blob/bootstrap3/README.adoc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140317/a35d38aa/attachment.bin 

From pmuir at redhat.com  Mon Mar 17 07:25:07 2014
From: pmuir at redhat.com (Pete Muir)
Date: Mon, 17 Mar 2014 11:25:07 +0000
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
Message-ID: <7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>

There are no ?best match? semantics in CDI I know of?

On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:

> Funny that this comes up now.  I actually hacked into my coworker's
> code using an observer on any object.
> 
> I always assumed the use of @Any in the examples came from a different
> version of the event observer pattern where it was a best match, not
> an any match.
> 
> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>> Yeah, agreed, this is something I've puzzled over before.
>> 
>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>> 
>>> Hi all
>>> 
>>> 
>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>> 
>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>> 
>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>> 
>>> If you write :
>>> @Inject Event<Payload> payLoadEvent;
>>> or
>>> @Inject @Any Event<Payload> payLoadEvent;
>>> 
>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>> 
>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>> 
>>> Antoine
>>> 
>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>> [2] https://issues.jboss.org/browse/CDI-422
>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>> [4] https://github.com/antoinesd/EventsTest
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev



From issues at jboss.org  Mon Mar 17 07:38:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 17 Mar 2014 07:38:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-331) Instance.iterator() shouldn't
 include non-alternatives that haven't been replaced
In-Reply-To: <JIRA.12486116.1362388773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486116.1362388773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486116.1362388773000.20635.1395056291265@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-331:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge  (was: )

    
> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
>                 Key: CDI-331
>                 URL: https://issues.jboss.org/browse/CDI-331
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>    Affects Versions: 1.1.PRD
>            Reporter: Jozef Hartinger
>            Assignee: Pete Muir
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> ? Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following 
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From antoine at sabot-durand.net  Mon Mar 17 07:48:28 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 17 Mar 2014 12:48:28 +0100
Subject: [cdi-dev] Tonight's meeting
Message-ID: <9C12E309-C7E3-44B6-AD32-4B4899B34342@sabot-durand.net>

Hi all,

The end of the MR is getting closer and we still have 12 tickets open (20 tickets resolved so far). You can still pick easy tickets in this list [1]

In today?s meeting I think we should talk about the list of ? Not Ready to fix issues ? [2] (issues that require discussion or analysis). More specifically

CDI-408 (@Observes and @Produces as bean defining annotation). The RTFM option is the chosen one, but do we had something to the spec ?
CDI-280 (Bean term clarification). To officially decide its removal from the MR like Jozef, Martin and I asked.
CDi-411 an important issue with no input since the beginning of the MR

I?d like also to come back on the inconsistency in Event behavior regarding @Any discovered during CDI-422. I really think we should at least add a mention and correct example in the spec.

If you have other tickets of importance please answer to this mail so everybody will be able to prepare the meeting.

Regards,

Antoine


 [1] : https://issues.jboss.org/issues/?filter=12320805
 [2] : https://issues.jboss.org/issues/?filter=12321017
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140317/4187310f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140317/4187310f/attachment.bin 

From antoine at sabot-durand.net  Mon Mar 17 07:49:08 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 17 Mar 2014 12:49:08 +0100
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
Message-ID: <044A81CF-8AA6-47BA-955E-64158F4B3309@sabot-durand.net>

I think we should talk about this in our weekly meeting today.


Le 17 mars 2014 ? 12:25, Pete Muir <pmuir at redhat.com> a ?crit :

> There are no ?best match? semantics in CDI I know of?
> 
> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
> 
>> Funny that this comes up now.  I actually hacked into my coworker's
>> code using an observer on any object.
>> 
>> I always assumed the use of @Any in the examples came from a different
>> version of the event observer pattern where it was a best match, not
>> an any match.
>> 
>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>> Yeah, agreed, this is something I've puzzled over before.
>>> 
>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>> 
>>>> Hi all
>>>> 
>>>> 
>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>> 
>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>> 
>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>> 
>>>> If you write :
>>>> @Inject Event<Payload> payLoadEvent;
>>>> or
>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>> 
>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>> 
>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>> 
>>>> Antoine
>>>> 
>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>> [4] https://github.com/antoinesd/EventsTest
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 

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

From john.d.ament at gmail.com  Mon Mar 17 07:56:39 2014
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 17 Mar 2014 07:56:39 -0400
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
Message-ID: <CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>

Correct, I don't believe best match is in any of the CDI spec.

However, this comes straight from Ken's book:

Say we have observer methods such as the following:

public void afterFictionBookAdded(@Observes @Book(FICTION)
  @Added Book book) { ... }

public void afterBookAdded(@Observes @Added Book book) { ... }

public void onBookEvent(@Observes Book book) { ... }

In such cases, only afterFictionBookAdded() will be called as it
matches the fired event with @Added and @Book(FICTION).

Now say we had an observer method such as the following:

public void afterAdding(@Observes @Any Book book) { ... }

The preceding observer method would also be notified, as @Any informs
Weld that we want to be notified of all Book events, irrespective of
what event qualifiers may be set.

On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
> There are no "best match" semantics in CDI I know of...
>
> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>
>> Funny that this comes up now.  I actually hacked into my coworker's
>> code using an observer on any object.
>>
>> I always assumed the use of @Any in the examples came from a different
>> version of the event observer pattern where it was a best match, not
>> an any match.
>>
>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>> Yeah, agreed, this is something I've puzzled over before.
>>>
>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>
>>>> Hi all
>>>>
>>>>
>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>
>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>
>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>
>>>> If you write :
>>>> @Inject Event<Payload> payLoadEvent;
>>>> or
>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>
>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>
>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>
>>>> Antoine
>>>>
>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>> [4] https://github.com/antoinesd/EventsTest
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>


From issues at jboss.org  Mon Mar 17 12:44:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 17 Mar 2014 12:44:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-381) Additional implementations of
 Request Context
In-Reply-To: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494579.1371584449000.21854.1395074650706@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-381:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Additional implementations of Request Context
> ---------------------------------------------
>
>                 Key: CDI-381
>                 URL: https://issues.jboss.org/browse/CDI-381
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_api_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that?  The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes.  It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 17 12:44:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 17 Mar 2014 12:44:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-380) Clarify SessionScoped
In-Reply-To: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494577.1371584170000.21856.1395074650817@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-380:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Clarify SessionScoped
> ---------------------
>
>                 Key: CDI-380
>                 URL: https://issues.jboss.org/browse/CDI-380
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The javadocs say:
> The request context is destroyed:
>    - at the end of the servlet request, after the service() method, all
>      doFilter() methods, and all requestDestroyed() and onComplete()
>      notifications return,
> ...
> The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListeners have been called, and at the very end of any request in
> which invalidate() was called, after all filters and ServletRequestListeners
> have been called.
> Those definitions are different.
> The session context rule seems to be a combination of "or" items that
> include some "and" items.  It's difficult to parse.  It would be clearer
> if it was written as a list.  And, like request scoped, it would be clearer
> if it described when the session scope/context is created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 17 14:04:10 2014
From: issues at jboss.org (Joseph Snyder (JIRA))
Date: Mon, 17 Mar 2014 14:04:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.22106.1395079450644@jira02.app.mwc.hst.phx2.redhat.com>


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

Joseph Snyder commented on CDI-408:
-----------------------------------

Option 3 for me.  Unless the likelihood of having an app with @Produces/@Observes but no other bean-defining annotationa is high.  If that is the case then option 1 makes more sense to me.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 17 14:16:12 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Mon, 17 Mar 2014 14:16:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.22131.1395080172273@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene commented on CDI-408:
----------------------------------

I should clarify that my preference for Option 1 was only because I didn't like the other two options. 2 logs a warning that should already be generally known (and could be too verbose). 3 encourages "all". To be clear, I would also go for a different option (4): Tell the user to put a defining annotation on the class if they want it picked up.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 17 14:28:10 2014
From: issues at jboss.org (Joe Bergmark (JIRA))
Date: Mon, 17 Mar 2014 14:28:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.22143.1395080890587@jira02.app.mwc.hst.phx2.redhat.com>


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

Joe Bergmark commented on CDI-408:
----------------------------------

I also vote Option 3.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Tue Mar 18 03:58:14 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 18 Mar 2014 08:58:14 +0100
Subject: [cdi-dev] Yesterday's meeting
Message-ID: <E9CD95C5-7708-4271-A45D-32A300FA9ED7@sabot-durand.net>

Hi all,

You?ll find yesterday?s meeting minutes here [1]. Unassigned Actions are mine.
Full meeting log is there [2]


[1] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346.2014-03-17-16.50.html
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346.2014-03-17-16.50.log.html

Antoine Sabot-Durand
???????????????
Twitter : @antoine_sd
CDI co-spec lead & eco-system development
Agorava tech lead

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140318/eccab958/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140318/eccab958/attachment.bin 

From issues at jboss.org  Tue Mar 18 05:10:10 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 18 Mar 2014 05:10:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.22813.1395133810744@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-411:
-------------------------------------

I think that we should not go into details in the spec and only say that the implementation must read the request parameter in a way that does not prevent filters/servlets from setting request encoding / parsing the body themselves.
                
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Tue Mar 18 05:17:37 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 18 Mar 2014 10:17:37 +0100
Subject: [cdi-dev] Link to specification 1.2 snapshot
Message-ID: <A67A43F3-F2B8-4852-A4C5-13D99FF51DDC@sabot-durand.net>

Hi all,

As requested yesterday by Martin, you?ll find the current snapshot of CDI 1.2 specification here:

https://dl.dropboxusercontent.com/u/2898173/cdi-spec-snapshot.html

If one of you know an easy solution to visually show differences between two html file I could also publish the current spec at the new format to show where the modification were made.

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

From issues at jboss.org  Tue Mar 18 05:20:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 18 Mar 2014 05:20:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.22836.1395134411918@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Do you have a suggestion to were we could put this remark in the spec?
                
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Tue Mar 18 06:50:37 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 18 Mar 2014 11:50:37 +0100
Subject: [cdi-dev] Link to specification 1.2 snapshot
In-Reply-To: <A67A43F3-F2B8-4852-A4C5-13D99FF51DDC@sabot-durand.net>
References: <A67A43F3-F2B8-4852-A4C5-13D99FF51DDC@sabot-durand.net>
Message-ID: <28F9B32D-C92B-4937-86A6-A3DFDC257CDB@sabot-durand.net>

I?ve just published current 1.1 specification and comparison with the 1.2 snapshots.

To sum up here are the different docs and links :

Current CDI 1.1 [1]
CDI 1.2 snaphsot [2]
Comparison between both [3] (differences adding, and deleting. If you have a better tool than www.changedetection.com do that please let me know)

Antoine

[1] https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html
[2] https://dl.dropboxusercontent.com/u/2898173/cdi-spec-snapshot.html
[3] https://dl.dropboxusercontent.com/u/2898173/cdi-spec-compare.html


Le 18 mars 2014 ? 10:17, Antoine Sabot-Durand <antoine at sabot-durand.net> a ?crit :

> Hi all,
> 
> As requested yesterday by Martin, you?ll find the current snapshot of CDI 1.2 specification here:
> 
> https://dl.dropboxusercontent.com/u/2898173/cdi-spec-snapshot.html
> 
> If one of you know an easy solution to visually show differences between two html file I could also publish the current spec at the new format to show where the modification were made.
> 
> Antoine

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

From issues at jboss.org  Tue Mar 18 07:08:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Tue, 18 Mar 2014 07:08:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.23126.1395140890866@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-411:
-------------------------------

Append a sentence to the second section Jozef quotes in the description.
                
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From pmuir at redhat.com  Tue Mar 18 07:11:31 2014
From: pmuir at redhat.com (Pete Muir)
Date: Tue, 18 Mar 2014 11:11:31 +0000
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
	<CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
Message-ID: <5230EA05-2266-4646-B36B-49FBA788DCB2@redhat.com>

Ken?s book is correct in this I think.

On 17 Mar 2014, at 11:56, John D. Ament <john.d.ament at gmail.com> wrote:

> Correct, I don't believe best match is in any of the CDI spec.
> 
> However, this comes straight from Ken's book:
> 
> Say we have observer methods such as the following:
> 
> public void afterFictionBookAdded(@Observes @Book(FICTION)
>  @Added Book book) { ... }
> 
> public void afterBookAdded(@Observes @Added Book book) { ... }
> 
> public void onBookEvent(@Observes Book book) { ... }
> 
> In such cases, only afterFictionBookAdded() will be called as it
> matches the fired event with @Added and @Book(FICTION).
> 
> Now say we had an observer method such as the following:
> 
> public void afterAdding(@Observes @Any Book book) { ... }
> 
> The preceding observer method would also be notified, as @Any informs
> Weld that we want to be notified of all Book events, irrespective of
> what event qualifiers may be set.
> 
> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>> There are no "best match" semantics in CDI I know of...
>> 
>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>> 
>>> Funny that this comes up now.  I actually hacked into my coworker's
>>> code using an observer on any object.
>>> 
>>> I always assumed the use of @Any in the examples came from a different
>>> version of the event observer pattern where it was a best match, not
>>> an any match.
>>> 
>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>>> Yeah, agreed, this is something I've puzzled over before.
>>>> 
>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>> 
>>>>> Hi all
>>>>> 
>>>>> 
>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>> 
>>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>> 
>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>> 
>>>>> If you write :
>>>>> @Inject Event<Payload> payLoadEvent;
>>>>> or
>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>> 
>>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>> 
>>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>> 
>>>>> Antoine
>>>>> 
>>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>>> [4] https://github.com/antoinesd/EventsTest
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 



From issues at jboss.org  Tue Mar 18 07:12:10 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Tue, 18 Mar 2014 07:12:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.23134.1395141130615@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-408:
-------------------------------

I agree with [~jason.greene], I don't want to extend the behavior, and instead to make it clear you need to use a class level annotation to make it a bean.
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 18 07:46:15 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 18 Mar 2014 07:46:15 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.23257.1395143175611@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba commented on CDI-408:
----------------------------------

[~pmuir] your comment reminds me that the following producer should not be discovered either:
{code:java}
class Producer {
  @Produces @ApplicationScoped
  Foo produce() {
    ... 
  }
}
{code}
Also not very intuitive for users although legal and covered in (among others) "5.1.2 Enabled and disabled beans".
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From john.d.ament at gmail.com  Tue Mar 18 08:10:30 2014
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 18 Mar 2014 08:10:30 -0400
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <5230EA05-2266-4646-B36B-49FBA788DCB2@redhat.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
	<CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
	<5230EA05-2266-4646-B36B-49FBA788DCB2@redhat.com>
Message-ID: <CAOqetn-0KuNVXiWXFJBZew-06ddk=evDpJc9dwHJq79wbm3QLw@mail.gmail.com>

Hmmm maybe it's a language semantics issue.

I put together a sample project in how I know it works today in Weld
1.x, 2.x and OWB.  https://github.com/johnament/cdi-events

You can run it using -Pweld-2, -Pweld-1 or -Powb

you'll see the first test pass, that correct hits all of the observer
methods from a single fired event.

The second one, which is my understanding of Ken's book's description,
assumes that only the best match and any are hit.  Considering that
both Weld and OWB hit all 5 observers, I'm assuming that this is the
intended result.

On Tue, Mar 18, 2014 at 7:11 AM, Pete Muir <pmuir at redhat.com> wrote:
> Ken's book is correct in this I think.
>
> On 17 Mar 2014, at 11:56, John D. Ament <john.d.ament at gmail.com> wrote:
>
>> Correct, I don't believe best match is in any of the CDI spec.
>>
>> However, this comes straight from Ken's book:
>>
>> Say we have observer methods such as the following:
>>
>> public void afterFictionBookAdded(@Observes @Book(FICTION)
>>  @Added Book book) { ... }
>>
>> public void afterBookAdded(@Observes @Added Book book) { ... }
>>
>> public void onBookEvent(@Observes Book book) { ... }
>>
>> In such cases, only afterFictionBookAdded() will be called as it
>> matches the fired event with @Added and @Book(FICTION).
>>
>> Now say we had an observer method such as the following:
>>
>> public void afterAdding(@Observes @Any Book book) { ... }
>>
>> The preceding observer method would also be notified, as @Any informs
>> Weld that we want to be notified of all Book events, irrespective of
>> what event qualifiers may be set.
>>
>> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>>> There are no "best match" semantics in CDI I know of...
>>>
>>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>>>
>>>> Funny that this comes up now.  I actually hacked into my coworker's
>>>> code using an observer on any object.
>>>>
>>>> I always assumed the use of @Any in the examples came from a different
>>>> version of the event observer pattern where it was a best match, not
>>>> an any match.
>>>>
>>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>>>> Yeah, agreed, this is something I've puzzled over before.
>>>>>
>>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>>>
>>>>>> Hi all
>>>>>>
>>>>>>
>>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>>>
>>>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>>>
>>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>>>
>>>>>> If you write :
>>>>>> @Inject Event<Payload> payLoadEvent;
>>>>>> or
>>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>>>
>>>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>>>
>>>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>>>
>>>>>> Antoine
>>>>>>
>>>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>>>> [4] https://github.com/antoinesd/EventsTest
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>


From mkouba at redhat.com  Tue Mar 18 07:20:12 2014
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 18 Mar 2014 12:20:12 +0100
Subject: [cdi-dev] Link to specification 1.2 snapshot
In-Reply-To: <28F9B32D-C92B-4937-86A6-A3DFDC257CDB@sabot-durand.net>
References: <A67A43F3-F2B8-4852-A4C5-13D99FF51DDC@sabot-durand.net>
	<28F9B32D-C92B-4937-86A6-A3DFDC257CDB@sabot-durand.net>
Message-ID: <53282BEC.1020901@redhat.com>

Thanks Antoine, that's really helpful! The table of contents does not
work for comparison, but it's just a minor issue ;-)

Martin

Dne 18.3.2014 11:50, Antoine Sabot-Durand napsal(a):
> I?ve just published current 1.1 specification and comparison with the 1.2 snapshots.
> 
> To sum up here are the different docs and links :
> 
> Current CDI 1.1 [1]
> CDI 1.2 snaphsot [2]
> Comparison between both [3] (differences adding, and deleting. If you have a better tool than www.changedetection.com do that please let me know)
> 
> Antoine
> 
> [1] https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html
> [2] https://dl.dropboxusercontent.com/u/2898173/cdi-spec-snapshot.html
> [3] https://dl.dropboxusercontent.com/u/2898173/cdi-spec-compare.html
> 
> 
> Le 18 mars 2014 ? 10:17, Antoine Sabot-Durand <antoine at sabot-durand.net> a ?crit :
> 
>> Hi all,
>>
>> As requested yesterday by Martin, you?ll find the current snapshot of CDI 1.2 specification here:
>>
>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec-snapshot.html
>>
>> If one of you know an easy solution to visually show differences between two html file I could also publish the current spec at the new format to show where the modification were made.
>>
>> Antoine
> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 

From antoine at sabot-durand.net  Tue Mar 18 10:14:38 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 18 Mar 2014 15:14:38 +0100
Subject: [cdi-dev] Link to specification 1.2 snapshot
In-Reply-To: <53282BEC.1020901@redhat.com>
References: <A67A43F3-F2B8-4852-A4C5-13D99FF51DDC@sabot-durand.net>
	<28F9B32D-C92B-4937-86A6-A3DFDC257CDB@sabot-durand.net>
	<53282BEC.1020901@redhat.com>
Message-ID: <70250D5F-86F1-48A9-8080-AF28196612E2@sabot-durand.net>

Thank you Martin,

Yes it?s not perfect but I took the first nice solution I found for that purpose. We could probably do better for the release notes?

Antoine


Le 18 mars 2014 ? 12:20, Martin Kouba <mkouba at redhat.com> a ?crit :

> Thanks Antoine, that's really helpful! The table of contents does not
> work for comparison, but it's just a minor issue ;-)
> 
> Martin
> 
> Dne 18.3.2014 11:50, Antoine Sabot-Durand napsal(a):
>> I?ve just published current 1.1 specification and comparison with the 1.2 snapshots.
>> 
>> To sum up here are the different docs and links :
>> 
>> Current CDI 1.1 [1]
>> CDI 1.2 snaphsot [2]
>> Comparison between both [3] (differences adding, and deleting. If you have a better tool than www.changedetection.com do that please let me know)
>> 
>> Antoine
>> 
>> [1] https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html
>> [2] https://dl.dropboxusercontent.com/u/2898173/cdi-spec-snapshot.html
>> [3] https://dl.dropboxusercontent.com/u/2898173/cdi-spec-compare.html
>> 
>> 
>> Le 18 mars 2014 ? 10:17, Antoine Sabot-Durand <antoine at sabot-durand.net> a ?crit :
>> 
>>> Hi all,
>>> 
>>> As requested yesterday by Martin, you?ll find the current snapshot of CDI 1.2 specification here:
>>> 
>>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec-snapshot.html
>>> 
>>> If one of you know an easy solution to visually show differences between two html file I could also publish the current spec at the new format to show where the modification were made.
>>> 
>>> Antoine
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 

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

From antoine at sabot-durand.net  Tue Mar 18 10:35:45 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 18 Mar 2014 15:35:45 +0100
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
	<CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
Message-ID: <7212BD9A-FD2A-468C-B009-1CCA46666D8E@sabot-durand.net>

John,

Sorry but it?s wrong. According to 10.2 in 1.1 spec [1] if you launch an event with @Added and @Book(Fiction) all the observers with a subset of these qualifiers (including empty set) will be called. Here that will be 

afterFictionBookAdded
afterBookAdded
onBookEvent

As I told when I started this thread (please read the IRC transcript if you want to catch up the conversation), this is how it is supposed to work in the spec and hopefully this is how it works in OWB and Weld 1 and 2 according to the tests I created [2] before starting this thread.

That brings 2 questions :

- The role of @Any regarding Event<> and @Observes qualification (it seems totally useless) and the fact that event examples in the spec use @Any (that bring a lot of confusion especially regarding next point)
- More generally the fact that event qualification work totally differently than standard qualification and that we don?t mention it anywhere. Ok you can guess it by reading carefully, but most CDI user I spoke with regarding this point made the mistake.

Antoine


[1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution
[2] https://github.com/antoinesd/EventsTest


Le 17 mars 2014 ? 12:56, John D. Ament <john.d.ament at gmail.com> a ?crit :

> Correct, I don't believe best match is in any of the CDI spec.
> 
> However, this comes straight from Ken's book:
> 
> Say we have observer methods such as the following:
> 
> public void afterFictionBookAdded(@Observes @Book(FICTION)
>  @Added Book book) { ... }
> 
> public void afterBookAdded(@Observes @Added Book book) { ... }
> 
> public void onBookEvent(@Observes Book book) { ... }
> 
> In such cases, only afterFictionBookAdded() will be called as it
> matches the fired event with @Added and @Book(FICTION).
> 
> Now say we had an observer method such as the following:
> 
> public void afterAdding(@Observes @Any Book book) { ... }
> 
> The preceding observer method would also be notified, as @Any informs
> Weld that we want to be notified of all Book events, irrespective of
> what event qualifiers may be set.
> 
> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>> There are no "best match" semantics in CDI I know of...
>> 
>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>> 
>>> Funny that this comes up now.  I actually hacked into my coworker's
>>> code using an observer on any object.
>>> 
>>> I always assumed the use of @Any in the examples came from a different
>>> version of the event observer pattern where it was a best match, not
>>> an any match.
>>> 
>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>>> Yeah, agreed, this is something I've puzzled over before.
>>>> 
>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>> 
>>>>> Hi all
>>>>> 
>>>>> 
>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>> 
>>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>> 
>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>> 
>>>>> If you write :
>>>>> @Inject Event<Payload> payLoadEvent;
>>>>> or
>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>> 
>>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>> 
>>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>> 
>>>>> Antoine
>>>>> 
>>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>>> [4] https://github.com/antoinesd/EventsTest
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 

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

From antoine at sabot-durand.net  Tue Mar 18 10:47:05 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 18 Mar 2014 15:47:05 +0100
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <7212BD9A-FD2A-468C-B009-1CCA46666D8E@sabot-durand.net>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
	<CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
	<7212BD9A-FD2A-468C-B009-1CCA46666D8E@sabot-durand.net>
Message-ID: <7CB0C8A0-205B-411F-9592-072CB3BDF8DA@sabot-durand.net>

Forgot one point about metadata unavailability.

When I @Observes an event without a qualifier, I will catch all the events of this type with whatever qualifier(s) they have. and I have no mean to get the set of qualifiers on the event I caught. Could be a real problem for some use case?

A mission for CDI 2.0 I guess?

Antoine


Le 18 mars 2014 ? 15:35, Antoine Sabot-Durand <antoine at sabot-durand.net> a ?crit :

> John,
> 
> Sorry but it?s wrong. According to 10.2 in 1.1 spec [1] if you launch an event with @Added and @Book(Fiction) all the observers with a subset of these qualifiers (including empty set) will be called. Here that will be 
> 
> afterFictionBookAdded
> afterBookAdded
> onBookEvent
> 
> As I told when I started this thread (please read the IRC transcript if you want to catch up the conversation), this is how it is supposed to work in the spec and hopefully this is how it works in OWB and Weld 1 and 2 according to the tests I created [2] before starting this thread.
> 
> That brings 2 questions :
> 
> - The role of @Any regarding Event<> and @Observes qualification (it seems totally useless) and the fact that event examples in the spec use @Any (that bring a lot of confusion especially regarding next point)
> - More generally the fact that event qualification work totally differently than standard qualification and that we don?t mention it anywhere. Ok you can guess it by reading carefully, but most CDI user I spoke with regarding this point made the mistake.
> 
> Antoine
> 
> 
> [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution
> [2] https://github.com/antoinesd/EventsTest
> 
> 
> Le 17 mars 2014 ? 12:56, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
>> Correct, I don't believe best match is in any of the CDI spec.
>> 
>> However, this comes straight from Ken's book:
>> 
>> Say we have observer methods such as the following:
>> 
>> public void afterFictionBookAdded(@Observes @Book(FICTION)
>> @Added Book book) { ... }
>> 
>> public void afterBookAdded(@Observes @Added Book book) { ... }
>> 
>> public void onBookEvent(@Observes Book book) { ... }
>> 
>> In such cases, only afterFictionBookAdded() will be called as it
>> matches the fired event with @Added and @Book(FICTION).
>> 
>> Now say we had an observer method such as the following:
>> 
>> public void afterAdding(@Observes @Any Book book) { ... }
>> 
>> The preceding observer method would also be notified, as @Any informs
>> Weld that we want to be notified of all Book events, irrespective of
>> what event qualifiers may be set.
>> 
>> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>>> There are no "best match" semantics in CDI I know of...
>>> 
>>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>>> 
>>>> Funny that this comes up now.  I actually hacked into my coworker's
>>>> code using an observer on any object.
>>>> 
>>>> I always assumed the use of @Any in the examples came from a different
>>>> version of the event observer pattern where it was a best match, not
>>>> an any match.
>>>> 
>>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>>>> Yeah, agreed, this is something I've puzzled over before.
>>>>> 
>>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>>> 
>>>>>> Hi all
>>>>>> 
>>>>>> 
>>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>>> 
>>>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>>> 
>>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>>> 
>>>>>> If you write :
>>>>>> @Inject Event<Payload> payLoadEvent;
>>>>>> or
>>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>>> 
>>>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>>> 
>>>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>>> 
>>>>>> Antoine
>>>>>> 
>>>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>>>> [4] https://github.com/antoinesd/EventsTest
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
> 

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

From issues at jboss.org  Tue Mar 18 11:00:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 18 Mar 2014 11:00:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.24054.1395154813181@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Yes [~pmuir] and [~jason.greene] we all agrre on that (I hope so) for me it was implicit that option 3) includes a mention in the spec regarding that, while option 2) would warn the user at boot time.

Now the majority chose the option 3  (aka the RTFM option) we should be sure that the spec include something about it : "you shouldn't use default bean discovery mode to use Producers and Observers or annotate the beans that contains them with bean defining annotation (that's pretty clear). Should we spread it in different chapters (Producers and Event) or should we put it somewhere else ?

                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 18 11:00:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 18 Mar 2014 11:00:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.24066.1395154813731@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand edited comment on CDI-408 at 3/18/14 10:59 AM:
--------------------------------------------------------------------

Yes [~pmuir] and [~jason.greene] we all agree on that (I hope so). For me it was implicit that option 3) includes a mention in the spec regarding that, while option 2) would warn the user at boot time.

Now the majority chose the option 3  (aka the RTFM option) we should be sure that the spec include something about it : "you shouldn't use default bean discovery mode to use Producers and Observers or annotate the beans that contains them with bean defining annotation (that's pretty clear). Should we spread it in different chapters (Producers and Event) or should we put it somewhere else ?

                
      was (Author: antoinesabot-durand):
    Yes [~pmuir] and [~jason.greene] we all agrre on that (I hope so) for me it was implicit that option 3) includes a mention in the spec regarding that, while option 2) would warn the user at boot time.

Now the majority chose the option 3  (aka the RTFM option) we should be sure that the spec include something about it : "you shouldn't use default bean discovery mode to use Producers and Observers or annotate the beans that contains them with bean defining annotation (that's pretty clear). Should we spread it in different chapters (Producers and Event) or should we put it somewhere else ?

                  
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 18 11:04:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 18 Mar 2014 11:04:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.24080.1395155052439@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-280:
-------------------------------------

    Fix Version/s: TBD
                       (was: 1.2 Proposed)

    
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: TBD
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 18 11:04:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 18 Mar 2014 11:04:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage
 in the spec
In-Reply-To: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477622.1350925278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477622.1350925278000.24100.1395155053787@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Removed from CDI 1.2 scope : too big and too late
                
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
>                 Key: CDI-280
>                 URL: https://issues.jboss.org/browse/CDI-280
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mark Struberg
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: TBD
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Mar 18 11:10:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 18 Mar 2014 11:10:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.24137.1395155411854@jira02.app.mwc.hst.phx2.redhat.com>


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

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

this issue is related to other issues dealing with Bean Defining annotations
                
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From john.d.ament at gmail.com  Tue Mar 18 11:11:11 2014
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 18 Mar 2014 11:11:11 -0400
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <7CB0C8A0-205B-411F-9592-072CB3BDF8DA@sabot-durand.net>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
	<CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
	<7212BD9A-FD2A-468C-B009-1CCA46666D8E@sabot-durand.net>
	<7CB0C8A0-205B-411F-9592-072CB3BDF8DA@sabot-durand.net>
Message-ID: <CAOqetn-1fhh-vKoMrWDZU=0naqF0LEhsAoa4knQM5jfi50Rf2Q@mail.gmail.com>

Antoine,

No, I definitely side with your view point.  The issue around event
qualification is also confusing for developers I've brought in to CDI.

BTW, I think you added EventMetadata in 1.1.  See [1]

[1]: http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/EventMetadata.html

On Tue, Mar 18, 2014 at 10:47 AM, Antoine Sabot-Durand
<antoine at sabot-durand.net> wrote:
> Forgot one point about metadata unavailability.
>
> When I @Observes an event without a qualifier, I will catch all the events of this type with whatever qualifier(s) they have. and I have no mean to get the set of qualifiers on the event I caught. Could be a real problem for some use case...
>
> A mission for CDI 2.0 I guess...
>
> Antoine
>
>
> Le 18 mars 2014 ? 15:35, Antoine Sabot-Durand <antoine at sabot-durand.net> a ?crit :
>
>> John,
>>
>> Sorry but it's wrong. According to 10.2 in 1.1 spec [1] if you launch an event with @Added and @Book(Fiction) all the observers with a subset of these qualifiers (including empty set) will be called. Here that will be
>>
>> afterFictionBookAdded
>> afterBookAdded
>> onBookEvent
>>
>> As I told when I started this thread (please read the IRC transcript if you want to catch up the conversation), this is how it is supposed to work in the spec and hopefully this is how it works in OWB and Weld 1 and 2 according to the tests I created [2] before starting this thread.
>>
>> That brings 2 questions :
>>
>> - The role of @Any regarding Event<> and @Observes qualification (it seems totally useless) and the fact that event examples in the spec use @Any (that bring a lot of confusion especially regarding next point)
>> - More generally the fact that event qualification work totally differently than standard qualification and that we don't mention it anywhere. Ok you can guess it by reading carefully, but most CDI user I spoke with regarding this point made the mistake.
>>
>> Antoine
>>
>>
>> [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution
>> [2] https://github.com/antoinesd/EventsTest
>>
>>
>> Le 17 mars 2014 ? 12:56, John D. Ament <john.d.ament at gmail.com> a ?crit :
>>
>>> Correct, I don't believe best match is in any of the CDI spec.
>>>
>>> However, this comes straight from Ken's book:
>>>
>>> Say we have observer methods such as the following:
>>>
>>> public void afterFictionBookAdded(@Observes @Book(FICTION)
>>> @Added Book book) { ... }
>>>
>>> public void afterBookAdded(@Observes @Added Book book) { ... }
>>>
>>> public void onBookEvent(@Observes Book book) { ... }
>>>
>>> In such cases, only afterFictionBookAdded() will be called as it
>>> matches the fired event with @Added and @Book(FICTION).
>>>
>>> Now say we had an observer method such as the following:
>>>
>>> public void afterAdding(@Observes @Any Book book) { ... }
>>>
>>> The preceding observer method would also be notified, as @Any informs
>>> Weld that we want to be notified of all Book events, irrespective of
>>> what event qualifiers may be set.
>>>
>>> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>>>> There are no "best match" semantics in CDI I know of...
>>>>
>>>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>>>>
>>>>> Funny that this comes up now.  I actually hacked into my coworker's
>>>>> code using an observer on any object.
>>>>>
>>>>> I always assumed the use of @Any in the examples came from a different
>>>>> version of the event observer pattern where it was a best match, not
>>>>> an any match.
>>>>>
>>>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>>>>> Yeah, agreed, this is something I've puzzled over before.
>>>>>>
>>>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>>>>
>>>>>>> Hi all
>>>>>>>
>>>>>>>
>>>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>>>>
>>>>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>>>>
>>>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>>>>
>>>>>>> If you write :
>>>>>>> @Inject Event<Payload> payLoadEvent;
>>>>>>> or
>>>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>>>>
>>>>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>>>>
>>>>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>>>>
>>>>>>> Antoine
>>>>>>>
>>>>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>>>>> [4] https://github.com/antoinesd/EventsTest
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>
>


From antoine at sabot-durand.net  Tue Mar 18 11:20:01 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 18 Mar 2014 16:20:01 +0100
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <CAOqetn-1fhh-vKoMrWDZU=0naqF0LEhsAoa4knQM5jfi50Rf2Q@mail.gmail.com>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
	<CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
	<7212BD9A-FD2A-468C-B009-1CCA46666D8E@sabot-durand.net>
	<7CB0C8A0-205B-411F-9592-072CB3BDF8DA@sabot-durand.net>
	<CAOqetn-1fhh-vKoMrWDZU=0naqF0LEhsAoa4knQM5jfi50Rf2Q@mail.gmail.com>
Message-ID: <3B50D956-A0AC-46E4-B075-0E9C37A49212@sabot-durand.net>

Thanks John, I missed this eventMetadata CDI 1.1 addition :-). I?m not sure to understand what you mean by starting your mail by ? No, I side with your view point ?.
The way events are working seem to have been the result of long thought [1]. Personnaly I don?t want to change the way it?s working now, I only want to make it clear for users (and for us apparently).

As it was decided in yesterday meeting, we should create a ticket on the subject to classify the event chapter.

Do you agree ?

Antoine

[1] https://issues.jboss.org/browse/CDI-7

Le 18 mars 2014 ? 16:11, John D. Ament <john.d.ament at gmail.com> a ?crit :

> Antoine,
> 
> No, I definitely side with your view point.  The issue around event
> qualification is also confusing for developers I've brought in to CDI.
> 
> BTW, I think you added EventMetadata in 1.1.  See [1]
> 
> [1]: http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/EventMetadata.html
> 
> On Tue, Mar 18, 2014 at 10:47 AM, Antoine Sabot-Durand
> <antoine at sabot-durand.net> wrote:
>> Forgot one point about metadata unavailability.
>> 
>> When I @Observes an event without a qualifier, I will catch all the events of this type with whatever qualifier(s) they have. and I have no mean to get the set of qualifiers on the event I caught. Could be a real problem for some use case...
>> 
>> A mission for CDI 2.0 I guess...
>> 
>> Antoine
>> 
>> 
>> Le 18 mars 2014 ? 15:35, Antoine Sabot-Durand <antoine at sabot-durand.net> a ?crit :
>> 
>>> John,
>>> 
>>> Sorry but it's wrong. According to 10.2 in 1.1 spec [1] if you launch an event with @Added and @Book(Fiction) all the observers with a subset of these qualifiers (including empty set) will be called. Here that will be
>>> 
>>> afterFictionBookAdded
>>> afterBookAdded
>>> onBookEvent
>>> 
>>> As I told when I started this thread (please read the IRC transcript if you want to catch up the conversation), this is how it is supposed to work in the spec and hopefully this is how it works in OWB and Weld 1 and 2 according to the tests I created [2] before starting this thread.
>>> 
>>> That brings 2 questions :
>>> 
>>> - The role of @Any regarding Event<> and @Observes qualification (it seems totally useless) and the fact that event examples in the spec use @Any (that bring a lot of confusion especially regarding next point)
>>> - More generally the fact that event qualification work totally differently than standard qualification and that we don't mention it anywhere. Ok you can guess it by reading carefully, but most CDI user I spoke with regarding this point made the mistake.
>>> 
>>> Antoine
>>> 
>>> 
>>> [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution
>>> [2] https://github.com/antoinesd/EventsTest
>>> 
>>> 
>>> Le 17 mars 2014 ? 12:56, John D. Ament <john.d.ament at gmail.com> a ?crit :
>>> 
>>>> Correct, I don't believe best match is in any of the CDI spec.
>>>> 
>>>> However, this comes straight from Ken's book:
>>>> 
>>>> Say we have observer methods such as the following:
>>>> 
>>>> public void afterFictionBookAdded(@Observes @Book(FICTION)
>>>> @Added Book book) { ... }
>>>> 
>>>> public void afterBookAdded(@Observes @Added Book book) { ... }
>>>> 
>>>> public void onBookEvent(@Observes Book book) { ... }
>>>> 
>>>> In such cases, only afterFictionBookAdded() will be called as it
>>>> matches the fired event with @Added and @Book(FICTION).
>>>> 
>>>> Now say we had an observer method such as the following:
>>>> 
>>>> public void afterAdding(@Observes @Any Book book) { ... }
>>>> 
>>>> The preceding observer method would also be notified, as @Any informs
>>>> Weld that we want to be notified of all Book events, irrespective of
>>>> what event qualifiers may be set.
>>>> 
>>>> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>>>>> There are no "best match" semantics in CDI I know of...
>>>>> 
>>>>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>>>>> 
>>>>>> Funny that this comes up now.  I actually hacked into my coworker's
>>>>>> code using an observer on any object.
>>>>>> 
>>>>>> I always assumed the use of @Any in the examples came from a different
>>>>>> version of the event observer pattern where it was a best match, not
>>>>>> an any match.
>>>>>> 
>>>>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>>>>>> Yeah, agreed, this is something I've puzzled over before.
>>>>>>> 
>>>>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>>>>> 
>>>>>>>> Hi all
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>>>>> 
>>>>>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>>>>> 
>>>>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>>>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>>>>> 
>>>>>>>> If you write :
>>>>>>>> @Inject Event<Payload> payLoadEvent;
>>>>>>>> or
>>>>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>>>>> 
>>>>>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>>>>> 
>>>>>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>>>>> 
>>>>>>>> Antoine
>>>>>>>> 
>>>>>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>>>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>>>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>>>>>> [4] https://github.com/antoinesd/EventsTest
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>> 
>> 

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

From john.d.ament at gmail.com  Tue Mar 18 11:37:08 2014
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 18 Mar 2014 11:37:08 -0400
Subject: [cdi-dev] Tests on observer resolution
In-Reply-To: <3B50D956-A0AC-46E4-B075-0E9C37A49212@sabot-durand.net>
References: <DECDA50B-CF15-4DBE-991C-3B37A5475588@sabot-durand.net>
	<48D10E5B-94BD-46E2-8B39-720BCC6B2C76@redhat.com>
	<CAOqetn-SKZ2qL=ZT6274jnaohy_Hf0TQFw7an+F8AiCW8-97CQ@mail.gmail.com>
	<7D64F63E-A79C-450E-B06C-5F1015BD1DE7@redhat.com>
	<CAOqetn8CpJYZNX7AkzkXzCJFP=KqSyDsiamtt=rtORqyVi5Gqg@mail.gmail.com>
	<7212BD9A-FD2A-468C-B009-1CCA46666D8E@sabot-durand.net>
	<7CB0C8A0-205B-411F-9592-072CB3BDF8DA@sabot-durand.net>
	<CAOqetn-1fhh-vKoMrWDZU=0naqF0LEhsAoa4knQM5jfi50Rf2Q@mail.gmail.com>
	<3B50D956-A0AC-46E4-B075-0E9C37A49212@sabot-durand.net>
Message-ID: <CAOqetn_21zYexe-Nyy8+Lrcq9WPMSLFfUXPC1hV-a_L_RT8FgA@mail.gmail.com>

Yes! Thanks for finding that, I knew the argument over which specific
ones were called was had at some point (I even discussed w/ Pete at
JUDcon around the same time as this ticket, w/r/t some SeamJMS
limitations because of the current pattern).  It seemed like you were
interpreting my email as "no, it should be working this other way"
when in fact I was siding with the current approach.  Agreed, at this
point the way it works is the way it works.  I don't think we should
modify behavior.  One thing to consider for 2.0 is a BestMatchEvent
that functionally works the same, but the qualifiers use a best match
algorithm so that observer method resolution is limited to qualifiers
that best match (rather than all being received) the injection
point/selector.  This would give some control to the caller on what is
observed.  Granted, I think for some use cases, there is a closer tie
between the event and the observered qualifiers (event an event object
or a properly qualified set).

- John

On Tue, Mar 18, 2014 at 11:20 AM, Antoine Sabot-Durand
<antoine at sabot-durand.net> wrote:
> Thanks John, I missed this eventMetadata CDI 1.1 addition :-). I'm not sure to understand what you mean by starting your mail by << No, I side with your view point >>.
> The way events are working seem to have been the result of long thought [1]. Personnaly I don't want to change the way it's working now, I only want to make it clear for users (and for us apparently).
>
> As it was decided in yesterday meeting, we should create a ticket on the subject to classify the event chapter.
>
> Do you agree ?
>
> Antoine
>
> [1] https://issues.jboss.org/browse/CDI-7
>
> Le 18 mars 2014 ? 16:11, John D. Ament <john.d.ament at gmail.com> a ?crit :
>
>> Antoine,
>>
>> No, I definitely side with your view point.  The issue around event
>> qualification is also confusing for developers I've brought in to CDI.
>>
>> BTW, I think you added EventMetadata in 1.1.  See [1]
>>
>> [1]: http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/EventMetadata.html
>>
>> On Tue, Mar 18, 2014 at 10:47 AM, Antoine Sabot-Durand
>> <antoine at sabot-durand.net> wrote:
>>> Forgot one point about metadata unavailability.
>>>
>>> When I @Observes an event without a qualifier, I will catch all the events of this type with whatever qualifier(s) they have. and I have no mean to get the set of qualifiers on the event I caught. Could be a real problem for some use case...
>>>
>>> A mission for CDI 2.0 I guess...
>>>
>>> Antoine
>>>
>>>
>>> Le 18 mars 2014 ? 15:35, Antoine Sabot-Durand <antoine at sabot-durand.net> a ?crit :
>>>
>>>> John,
>>>>
>>>> Sorry but it's wrong. According to 10.2 in 1.1 spec [1] if you launch an event with @Added and @Book(Fiction) all the observers with a subset of these qualifiers (including empty set) will be called. Here that will be
>>>>
>>>> afterFictionBookAdded
>>>> afterBookAdded
>>>> onBookEvent
>>>>
>>>> As I told when I started this thread (please read the IRC transcript if you want to catch up the conversation), this is how it is supposed to work in the spec and hopefully this is how it works in OWB and Weld 1 and 2 according to the tests I created [2] before starting this thread.
>>>>
>>>> That brings 2 questions :
>>>>
>>>> - The role of @Any regarding Event<> and @Observes qualification (it seems totally useless) and the fact that event examples in the spec use @Any (that bring a lot of confusion especially regarding next point)
>>>> - More generally the fact that event qualification work totally differently than standard qualification and that we don't mention it anywhere. Ok you can guess it by reading carefully, but most CDI user I spoke with regarding this point made the mistake.
>>>>
>>>> Antoine
>>>>
>>>>
>>>> [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution
>>>> [2] https://github.com/antoinesd/EventsTest
>>>>
>>>>
>>>> Le 17 mars 2014 ? 12:56, John D. Ament <john.d.ament at gmail.com> a ?crit :
>>>>
>>>>> Correct, I don't believe best match is in any of the CDI spec.
>>>>>
>>>>> However, this comes straight from Ken's book:
>>>>>
>>>>> Say we have observer methods such as the following:
>>>>>
>>>>> public void afterFictionBookAdded(@Observes @Book(FICTION)
>>>>> @Added Book book) { ... }
>>>>>
>>>>> public void afterBookAdded(@Observes @Added Book book) { ... }
>>>>>
>>>>> public void onBookEvent(@Observes Book book) { ... }
>>>>>
>>>>> In such cases, only afterFictionBookAdded() will be called as it
>>>>> matches the fired event with @Added and @Book(FICTION).
>>>>>
>>>>> Now say we had an observer method such as the following:
>>>>>
>>>>> public void afterAdding(@Observes @Any Book book) { ... }
>>>>>
>>>>> The preceding observer method would also be notified, as @Any informs
>>>>> Weld that we want to be notified of all Book events, irrespective of
>>>>> what event qualifiers may be set.
>>>>>
>>>>> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir at redhat.com> wrote:
>>>>>> There are no "best match" semantics in CDI I know of...
>>>>>>
>>>>>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament at gmail.com> wrote:
>>>>>>
>>>>>>> Funny that this comes up now.  I actually hacked into my coworker's
>>>>>>> code using an observer on any object.
>>>>>>>
>>>>>>> I always assumed the use of @Any in the examples came from a different
>>>>>>> version of the event observer pattern where it was a best match, not
>>>>>>> an any match.
>>>>>>>
>>>>>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir at redhat.com> wrote:
>>>>>>>> Yeah, agreed, this is something I've puzzled over before.
>>>>>>>>
>>>>>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>>>>>>>>
>>>>>>>>> Hi all
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422 [2], we started a discussion about Observer Resolution about a possible issue in the spec. I will not repeat what was said on the IRC, if you're interested you can check the transcript [3] from 09:43.
>>>>>>>>>
>>>>>>>>> To check if this was an issue or not I did some test this morning with different implementations. You can grab the tests on Github [4]
>>>>>>>>>
>>>>>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the one describe in the current spec, so there are no issue on this point.
>>>>>>>>> The only strange thing for me is that @Any seems totally useless regarding events firing
>>>>>>>>>
>>>>>>>>> If you write :
>>>>>>>>> @Inject Event<Payload> payLoadEvent;
>>>>>>>>> or
>>>>>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>>>>>>
>>>>>>>>> You'll always be allowed call payLoadEvent.select(new QualifierLiteral()) in both case...
>>>>>>>>>
>>>>>>>>> Perhaps this point can be discussed to see if we remove @Any from the examples in the spec or if we enforce its usage in the specification...
>>>>>>>>>
>>>>>>>>> Antoine
>>>>>>>>>
>>>>>>>>> [1] https://github.com/cdi-spec/cdi/pull/207
>>>>>>>>> [2] https://issues.jboss.org/browse/CDI-422
>>>>>>>>> [3] http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23jsr346.2014-03-05.log.html
>>>>>>>>> [4] https://github.com/antoinesd/EventsTest
>>>>>>>>> _______________________________________________
>>>>>>>>> cdi-dev mailing list
>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>
>>>
>


From antoine at sabot-durand.net  Wed Mar 19 11:30:50 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 19 Mar 2014 16:30:50 +0100
Subject: [cdi-dev] Back on bean defining annotations
Message-ID: <6363D538-A9CF-4EBB-B14F-610332D64AF7@sabot-durand.net>

Hi all,

Im? back with the main subject of this MR.

To resolve CDI-377 we decided to exclude from the ? Bean defining annotations ? set, all Pseudo Scope type (scope annotation having the meta annotation @Scope) except @Dependent.
So all normal scope annotation (built-in and user defined) are Bean Defining Annotation.

Now what about a normal scope added with :

1) BeforeBeanDiscovery.addScope(MyFirstScope.class,true,<true | false>) ?

And a pseudo scope added with : 

2) BeforeBeanDiscovery.addScope(MySecondScope.class,false,<true | false>) ?


For me MyFirstScope (defined in 1) should be a bean defining annotation while MySecondScope shouldn?t. 

Any thought ?

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

From issues at jboss.org  Wed Mar 19 12:34:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 19 Mar 2014 12:34:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.26896.1395246850571@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Your quote of the spec seems a bit old.
The current spec says

{quote}
The container must fire an event, before it processes a type, for:
? every Java class, interface or enum discovered
? each Java class, interface or enum that must be delivered to a ProcessAnnotatedType observer, where the event parameter
is annotated with @WithAnnotations.
{quote}

I think the use case of adding an annotation thru an {{AnnotatedType}} in {{BeforeBeanDiscovery.addAnnotatedType()}} or {{AferTypeDiscovery.addAnnotatedType()}} is very unlikely, but we could change the previous wording  by

{quote}
The container must fire an event, before it processes a type, for:
? every Java class, interface or enum discovered
? *every {{AnnotatedType}} representing a Java class, interface or enum added by {{BeforeBeanDiscovery.addAnnotatedType()}} or {{AferTypeDiscovery.addAnnotatedType()}}*
? each Java class, interface or enum that must be delivered to a ProcessAnnotatedType observer, where the event parameter
is annotated with @WithAnnotations.
{quote}

Wdyt ?
                
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Mar 20 04:16:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 04:16:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-381) Additional implementations of
 Request Context
In-Reply-To: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494579.1371584449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494579.1371584449000.28440.1395303372067@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-381 started by Antoine Sabot-Durand.

> Additional implementations of Request Context
> ---------------------------------------------
>
>                 Key: CDI-381
>                 URL: https://issues.jboss.org/browse/CDI-381
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_api_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that?  The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes.  It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Thu Mar 20 08:02:30 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 20 Mar 2014 13:02:30 +0100
Subject: [cdi-dev] Please review PR 218
Message-ID: <0EEDB14C-8751-4B70-A8E9-CC5FE220CB02@sabot-durand.net>

Hi all,

Just posted a new PR [1] about ticket CDI-381 [2]
Review should be quick.

Thanks,

Antoine

[1] https://github.com/cdi-spec/cdi/pull/218
[2] https://issues.jboss.org/browse/CDI-381






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

From issues at jboss.org  Thu Mar 20 08:08:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 08:08:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.29037.1395317290670@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-320:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Mar 20 10:06:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 10:06:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.29368.1395324371305@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-320 started by Antoine Sabot-Durand.

> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Mar 20 10:46:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 10:46:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-428) Qualifying behavior for events and
 Observes is very different than qualifying beans and Injection Point
In-Reply-To: <JIRA.12535580.1395326740206@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535580.1395326740206@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535580.1395326740206.29468.1395326772945@jira02.app.mwc.hst.phx2.redhat.com>

Antoine Sabot-Durand created CDI-428:
----------------------------------------

             Summary: Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point
                 Key: CDI-428
                 URL: https://issues.jboss.org/browse/CDI-428
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Events
    Affects Versions: 1.1.Final
            Reporter: Antoine Sabot-Durand
             Fix For: 1.2 Proposed


It should be more explicit that these behaves differently. The beginning of this possibility of confusion started with CDI-7. During CDI-422 resolution there was discussion about misunderstanding of these behavior.
Everybody agree with the current way it's working but the specification obviously of precision about these differences. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 20 10:48:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 10:48:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-428) Qualifying behavior for events and
 Observes is very different than qualifying beans and Injection Point
In-Reply-To: <JIRA.12535580.1395326740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535580.1395326740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535580.1395326740000.29476.1395326890852@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-428:
-------------------------------------

    Labels: CDI_spec_chge Ready_to_fix  (was: CDI_spec_chge)

    
> Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point
> -------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-428
>                 URL: https://issues.jboss.org/browse/CDI-428
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be more explicit that these behaves differently. The beginning of this possibility of confusion started with CDI-7. During CDI-422 resolution there was discussion about misunderstanding of these behavior.
> Everybody agree with the current way it's working but the specification obviously of precision about these differences. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jharting at redhat.com  Thu Mar 20 11:06:15 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 20 Mar 2014 16:06:15 +0100
Subject: [cdi-dev] Back on bean defining annotations
In-Reply-To: <6363D538-A9CF-4EBB-B14F-610332D64AF7@sabot-durand.net>
References: <6363D538-A9CF-4EBB-B14F-610332D64AF7@sabot-durand.net>
Message-ID: <532B03E7.4080103@redhat.com>

Agreed but this approach of splitting things too much seems overly 
complicated to me. Let's not tie the bean defining annotation definition 
to the @Scope/@NormalScope meta-annotation presence. Let's instead say 
that all normal scopes are bean defining annotations. It will then be 
implicit that an annotation is a bean defining if either it is annotated 
with @NormalScoped or is added as 
BeforeBeanDiscovery.addScope(MyFirstScope.class,true,<true | false>)

Jozef

On 03/19/2014 04:30 PM, Antoine Sabot-Durand wrote:
> Hi all,
>
> Im' back with the main subject of this MR.
>
> To resolve CDI-377 we decided to exclude from the ? Bean defining annotations ? set, all Pseudo Scope type (scope annotation having the meta annotation @Scope) except @Dependent.
> So all normal scope annotation (built-in and user defined) are Bean Defining Annotation.
>
> Now what about a normal scope added with :
>
> 1) BeforeBeanDiscovery.addScope(MyFirstScope.class,true,<true | false>) ?
>
> And a pseudo scope added with :
>
> 2) BeforeBeanDiscovery.addScope(MySecondScope.class,false,<true | false>) ?
>
>
> For me MyFirstScope (defined in 1) should be a bean defining annotation while MySecondScope shouldn't.
>
> Any thought ?
>
> Antoine
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

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

From issues at jboss.org  Thu Mar 20 11:56:12 2014
From: issues at jboss.org (=?UTF-8?Q?Ron_=C5=A0meral_=28JIRA=29?=)
Date: Thu, 20 Mar 2014 11:56:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.29612.1395330972614@jira02.app.mwc.hst.phx2.redhat.com>


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

Ron ?meral commented on CDI-320:
--------------------------------

The quoted text is from pre-1.1 spec snapshot, so it's indeed outdated.

However, the current wording is getting quite confusing again, IMHO, and several points should be made clear:
* the third point, which deals with {{@WithAnnotations}} doesn't seem to belong to the paragraph, as the paragraph talks about what the container must fire, not about what the observers must handle. The point seems redundant because the set of _every Java class, interface or enum discovered_ fully includes the set of _annotated_ Java classes, interfaces or enums discovered. 
* the second point says _"every AnnotatedType representing a Java class, interface or enum"_, but the javadoc for {{AnnotatedType}} says that it _Represents a Java class or interface._ (no {{enum}}). Maybe this should be made consistent, either by modifying the javadoc or the spec.

That said, I hope my understanding of the purpose and implementation of {{@WithAnnotations}} is correct.

Several minor issues:
* there's a typo in the proposed new point: _AferTypeDiscovery_ instead of _AfterTypeDiscovery_.
* also, the quantifiers "every" and "each" should be unified to just one of those. I suppose there's no difference in meaning;
* maybe also add commas (or semicolons?) at ends of lines/points.
                
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Mar 20 12:06:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 12:06:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.29629.1395331570860@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Thanks [~rsmeral]. In fact the discussion wen on in the PR. The last version I proposed is : 

{quote}
The container must fire an event, before it processes a type, for:
 * every Java class, interface (that is not an annotation) or enum discovered
 * each Java class, interface or enum that must be delivered to a ProcessAnnotatedType observer, where the event parameter
is annotated with @WithAnnotations.
{quote}

The same mention was added in 12.4. Check the PR to see it in situ : https://github.com/cdi-spec/cdi/pull/219.
Thanks for pointing the Javadoc as well. I'll port our modification (and enum addition) as soon as we'll have a final version in the spec.

                
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Mar 20 12:06:11 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 20 Mar 2014 12:06:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.29636.1395331571287@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on CDI-320:
-------------------------------------

{quote}the third point, which deals with @WithAnnotations doesn't seem to belong to the paragraph, as the paragraph talks about what the container must fire, not about what the observers must handle. The point seems redundant because the set of every Java class, interface or enum discovered fully includes the set of annotated Java classes, interfaces or enums discovered.{quote}

I think you are referring to this part:
{quote}each Java class, interface or enum that must be delivered to a ProcessAnnotatedType observer, where the event parameter
is annotated with @WithAnnotations.{quote}

This is indeed a leftover from pre-final version of CDI 1.1. This feature did not make it into the final version. We should remove this leftover.
                
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Mar 20 12:12:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 12:12:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.29646.1395331930789@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Seriously [~jharting]?
I must admit I found this sentence not very clear... Thanks both for that discovery. I remove it from the PR.
                
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Mar 20 12:32:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 12:32:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all Noraml Scopes
In-Reply-To: <JIRA.12535590.1395333093789@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093789@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093789.29708.1395333131292@jira02.app.mwc.hst.phx2.redhat.com>

Antoine Sabot-Durand created CDI-429:
----------------------------------------

             Summary: Consistency of all Noraml Scopes
                 Key: CDI-429
                 URL: https://issues.jboss.org/browse/CDI-429
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Contexts
    Affects Versions: 1.1.Final
            Reporter: Antoine Sabot-Durand
             Fix For: 1.2 Proposed


In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 20 12:34:11 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 20 Mar 2014 12:34:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all Normal Scopes
In-Reply-To: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093000.29722.1395333251983@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-429:
-------------------------------------

    Summary: Consistency of all Normal Scopes  (was: Consistency of all Noraml Scopes)

    
> Consistency of all Normal Scopes
> --------------------------------
>
>                 Key: CDI-429
>                 URL: https://issues.jboss.org/browse/CDI-429
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Mar 21 03:16:12 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 21 Mar 2014 03:16:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all built-in normal
	scopes
In-Reply-To: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093000.31168.1395386172087@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba updated CDI-429:
-----------------------------

    Summary: Consistency of all built-in normal scopes  (was: Consistency of all Normal Scopes)

    
> Consistency of all built-in normal scopes
> -----------------------------------------
>
>                 Key: CDI-429
>                 URL: https://issues.jboss.org/browse/CDI-429
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Mar 21 04:00:11 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 21 Mar 2014 04:00:11 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.31241.1395388811853@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-392:
-----------------------------------

As we agree that those sentences make no sense: should we remove those?
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Mar 21 07:06:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 21 Mar 2014 07:06:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.31719.1395399970935@jira02.app.mwc.hst.phx2.redhat.com>


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

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

+1
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Mar 21 08:28:10 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 21 Mar 2014 08:28:10 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-380) Clarify SessionScoped
In-Reply-To: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494577.1371584170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494577.1371584170000.31923.1395404890682@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-380 started by Antoine Sabot-Durand.

> Clarify SessionScoped
> ---------------------
>
>                 Key: CDI-380
>                 URL: https://issues.jboss.org/browse/CDI-380
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Joseph Snyder
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The javadocs say:
> The request context is destroyed:
>    - at the end of the servlet request, after the service() method, all
>      doFilter() methods, and all requestDestroyed() and onComplete()
>      notifications return,
> ...
> The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListeners have been called, and at the very end of any request in
> which invalidate() was called, after all filters and ServletRequestListeners
> have been called.
> Those definitions are different.
> The session context rule seems to be a combination of "or" items that
> include some "and" items.  It's difficult to parse.  It would be clearer
> if it was written as a list.  And, like request scoped, it would be clearer
> if it described when the session scope/context is created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 22 11:20:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 22 Mar 2014 11:20:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all built-in normal
	scopes
In-Reply-To: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093000.14.1395501612893@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-429:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Consistency of all built-in normal scopes
> -----------------------------------------
>
>                 Key: CDI-429
>                 URL: https://issues.jboss.org/browse/CDI-429
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 22 11:22:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 22 Mar 2014 11:22:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all built-in normal
	scopes
In-Reply-To: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093000.15.1395501733779@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-429:
-------------------------------------

    Labels: CDI_api_chge CDI_spec_chge reasd  (was: CDI_api_chge CDI_spec_chge)

    
> Consistency of all built-in normal scopes
> -----------------------------------------
>
>                 Key: CDI-429
>                 URL: https://issues.jboss.org/browse/CDI-429
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, reasd
>             Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 22 11:22:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 22 Mar 2014 11:22:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all built-in normal
	scopes
In-Reply-To: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093000.16.1395501733828@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-429:
-------------------------------------

    Labels: CDI_api_chge CDI_spec_chge Ready_to_fix  (was: CDI_api_chge CDI_spec_chge reasd)

    
> Consistency of all built-in normal scopes
> -----------------------------------------
>
>                 Key: CDI-429
>                 URL: https://issues.jboss.org/browse/CDI-429
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 22 11:24:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 22 Mar 2014 11:24:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all built-in normal
	scopes
In-Reply-To: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093000.17.1395501852822@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-429 started by Antoine Sabot-Durand.

> Consistency of all built-in normal scopes
> -----------------------------------------
>
>                 Key: CDI-429
>                 URL: https://issues.jboss.org/browse/CDI-429
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 22 12:54:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 22 Mar 2014 12:54:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-429) Consistency of all built-in normal
	scopes
In-Reply-To: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535590.1395333093000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535590.1395333093000.25.1395507252849@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Pull Request sent :
https://github.com/cdi-spec/cdi/pull/222
                
> Consistency of all built-in normal scopes
> -----------------------------------------
>
>                 Key: CDI-429
>                 URL: https://issues.jboss.org/browse/CDI-429
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 22 12:56:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 22 Mar 2014 12:56:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.29.1395507373007@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-398:
-------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Sun Mar 23 04:22:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sun, 23 Mar 2014 04:22:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.94.1395562933473@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-398 started by Antoine Sabot-Durand.

> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Sun Mar 23 05:41:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sun, 23 Mar 2014 05:41:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.126.1395567673050@jira02.app.mwc.hst.phx2.redhat.com>


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

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

https://github.com/cdi-spec/cdi/pull/223
                
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Mar 24 04:51:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 04:51:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.544.1395651073589@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-411:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 24 04:53:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 04:53:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.549.1395651192881@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-411:
-------------------------------------

    Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix  (was: CDI_spec_chge CDI_tck_chge)

    
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 24 04:57:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 04:57:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation
 conflicts with the Servlet spec
In-Reply-To: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526694.1386062528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526694.1386062528000.562.1395651433371@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-411 started by Antoine Sabot-Durand.

> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
>                 Key: CDI-411
>                 URL: https://issues.jboss.org/browse/CDI-411
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Java EE integration
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 24 07:15:14 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 07:15:14 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-427) Review all annotations for
 inclusion to bean defining annotations
In-Reply-To: <JIRA.12534745.1394617589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534745.1394617589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534745.1394617589000.945.1395659714107@jira02.app.mwc.hst.phx2.redhat.com>


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

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

To be consistent with the decision that's been chosen in CDI-408, I think we should stick to what was decided in CDI-377, CDI-404 and 406 (Normal Scope type, Interceptor, Decorator and Stereotype). Anyway, here's my POV on class level annotation not in Bean defining annotation set.

* Qualifiers (built-in or user defined). As @Qualifier are defined in JSR 330, we shouldn't take them to avoid the same issue than in CDI-377
*  @Alternative : could bring a lot of issue regarding if the bean this alternative replace has been detected as a bean. And since activating an alternative requiers using beans.xml, it's not very far to switch the bean-discovery-mode to all
* @Specialize : same remark about the specialized bean being considered as a bean
* @Typed : the only class level annotation that would be easily added to the set. But is it necessary ?

                
> Review all annotations for inclusion to bean defining annotations
> -----------------------------------------------------------------
>
>                 Key: CDI-427
>                 URL: https://issues.jboss.org/browse/CDI-427
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result.
> Two candidates that come to mind are @Alternative and @Specializes.
> This issue depends on the resolution of CDI-408

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 24 10:47:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 10:47:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated"
 and Producers/Observers in @Dependent beans
In-Reply-To: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525668.1384939473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525668.1384939473000.2770.1395672433969@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-408 started by Antoine Sabot-Durand.

> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
>                 Key: CDI-408
>                 URL: https://issues.jboss.org/browse/CDI-408
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>            Reporter: Jens Schumann
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>  
> Btw: Which JIRA version is CDI 1.1 Final? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Mar 24 10:59:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 10:59:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-372) clarify behaviour of implicit bean
	archive
In-Reply-To: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492219.1369101881000.2930.1395673153558@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-372:
----------------------------------------

    Assignee: Antoine Sabot-Durand

    
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
>                 Key: CDI-372
>                 URL: https://issues.jboss.org/browse/CDI-372
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Packaging and Deployment
>    Affects Versions: 1.1.PFD
>            Reporter: David Konecny
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> ? each Java class, interface or enum deployed in an explicit bean archive, and
> ? each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Mar 24 11:05:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 11:05:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-372) clarify behaviour of implicit bean
	archive
In-Reply-To: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492219.1369101881000.2944.1395673513718@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-372 started by Antoine Sabot-Durand.

> clarify behaviour of implicit bean archive
> ------------------------------------------
>
>                 Key: CDI-372
>                 URL: https://issues.jboss.org/browse/CDI-372
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Packaging and Deployment
>    Affects Versions: 1.1.PFD
>            Reporter: David Konecny
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> ? each Java class, interface or enum deployed in an explicit bean archive, and
> ? each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Mar 24 12:49:15 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 12:49:15 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-372) clarify behaviour of implicit bean
	archive
In-Reply-To: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492219.1369101881000.3529.1395679755411@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand edited comment on CDI-372 at 3/24/14 12:48 PM:
--------------------------------------------------------------------

https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDI-408
                
      was (Author: antoinesabot-durand):
    https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDi-428
                  
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
>                 Key: CDI-372
>                 URL: https://issues.jboss.org/browse/CDI-372
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Packaging and Deployment
>    Affects Versions: 1.1.PFD
>            Reporter: David Konecny
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> ? each Java class, interface or enum deployed in an explicit bean archive, and
> ? each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Mar 24 12:49:14 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 24 Mar 2014 12:49:14 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-372) clarify behaviour of implicit bean
	archive
In-Reply-To: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492219.1369101881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492219.1369101881000.3515.1395679754645@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand edited comment on CDI-372 at 3/24/14 12:48 PM:
--------------------------------------------------------------------

https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDi-428
                
      was (Author: antoinesabot-durand):
    https://github.com/cdi-spec/cdi/pull/225
This PR also resolve CDi-408
                  
> clarify behaviour of implicit bean archive
> ------------------------------------------
>
>                 Key: CDI-372
>                 URL: https://issues.jboss.org/browse/CDI-372
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Packaging and Deployment
>    Affects Versions: 1.1.PFD
>            Reporter: David Konecny
>            Assignee: Antoine Sabot-Durand
>            Priority: Minor
>              Labels: CDI_spec_chge
>             Fix For: 1.2 Proposed
>
>
> I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
> The container discovers:
> ? each Java class, interface or enum deployed in an explicit bean archive, and
> ? each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
> The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Mar 25 08:02:17 2014
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 25 Mar 2014 08:02:17 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-320) Clarify whether
 ProcessAnnotatedType should be fired for annotations
In-Reply-To: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484018.1359737286000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484018.1359737286000.5068.1395748937032@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Kouba updated CDI-320:
-----------------------------

    Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix  (was: CDI_spec_chge Ready_to_fix)

    
> Clarify whether ProcessAnnotatedType should be fired for annotations
> --------------------------------------------------------------------
>
>                 Key: CDI-320
>                 URL: https://issues.jboss.org/browse/CDI-320
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Portable Extensions
>            Reporter: Ron ?meral
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be stated clearly whether {{ProcessAnnotatedType}} should be fired for annotations.
> Currently, *11.5.6 ProcessAnnotatedType event* says:
> {quote}
> The container must fire an event, before it processes a type, for each:
> * Java class, interface or enum in a bean archive,
> {quote}
> The word "annotation" has been introduced into the above line and later reverted. 
> {quote}
> * Annotated type added by {{BeforeBeanDiscovery.addAnnotatedType()}},
> {quote}
> The wording used here, however, doesn't exclude the option of the annotated type being an Annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Mar 25 09:13:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 25 Mar 2014 09:13:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.5365.1395753193851@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reopened CDI-398:
--------------------------------------



Forgot to treat return types from producer fields and methods.
                
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Mar 26 05:27:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 26 Mar 2014 05:27:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-398) Clarify that an array with a
 variable component type or parameterized component type containing
 wildcards is not a valid bean type
In-Reply-To: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499736.1378106798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499736.1378106798000.8482.1395826033698@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-398 started by Antoine Sabot-Durand.

> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-398
>                 URL: https://issues.jboss.org/browse/CDI-398
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Beans
>    Affects Versions: 1.1.PFD
>            Reporter: Marko Luk?a
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> ? A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types. 
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Mar 26 06:45:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 26 Mar 2014 06:45:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-331) Instance.iterator() shouldn't
 include non-alternatives that haven't been replaced
In-Reply-To: <JIRA.12486116.1362388773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486116.1362388773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486116.1362388773000.8849.1395830713511@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand reassigned CDI-331:
----------------------------------------

    Assignee: Antoine Sabot-Durand  (was: Pete Muir)

    
> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
>                 Key: CDI-331
>                 URL: https://issues.jboss.org/browse/CDI-331
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>    Affects Versions: 1.1.PRD
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> ? Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following 
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Mar 26 07:33:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 26 Mar 2014 07:33:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-331) Instance.iterator() shouldn't
 include non-alternatives that haven't been replaced
In-Reply-To: <JIRA.12486116.1362388773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486116.1362388773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486116.1362388773000.9028.1395833593066@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-331 started by Antoine Sabot-Durand.

> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
>                 Key: CDI-331
>                 URL: https://issues.jboss.org/browse/CDI-331
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Resolution
>    Affects Versions: 1.1.PRD
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> ? Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following 
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Mar 26 12:59:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 26 Mar 2014 12:59:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-427) Review all annotations for
 inclusion to bean defining annotations
In-Reply-To: <JIRA.12534745.1394617589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534745.1394617589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534745.1394617589000.10964.1395853153622@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand resolved CDI-427.
--------------------------------------

    Resolution: Done


After discussion, no annotation had to be added to the list.
                
> Review all annotations for inclusion to bean defining annotations
> -----------------------------------------------------------------
>
>                 Key: CDI-427
>                 URL: https://issues.jboss.org/browse/CDI-427
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.1.FD
>            Reporter: Jozef Hartinger
>              Labels: CDI_spec_chge, CDI_tck_chge
>             Fix For: 1.2 Proposed
>
>
> The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result.
> Two candidates that come to mind are @Alternative and @Specializes.
> This issue depends on the resolution of CDI-408

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 27 10:12:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 27 Mar 2014 10:12:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes
 session bean is undefined
In-Reply-To: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.13747.1395929533409@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-220:
-------------------------------------

    Assignee: Antoine Sabot-Durand

    
> 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
>             Fix For: 1.2 Proposed
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 27 10:12:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 27 Mar 2014 10:12:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes
 session bean is undefined
In-Reply-To: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.13750.1395929533543@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-220 started by Antoine Sabot-Durand.

> 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
>             Fix For: 1.2 Proposed
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 27 10:30:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 27 Mar 2014 10:30:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes
 session bean is undefined
In-Reply-To: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.13797.1395930613965@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-220:
-------------------------------------

    Fix Version/s: TBD
                       (was: 1.2 Proposed)


Depend on CDI-280 clarification that was postpone for 2.0
                
> 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
>             Fix For: TBD
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 27 10:30:14 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 27 Mar 2014 10:30:14 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-220) behaviour of CDI bean @Specializes
 session bean is undefined
In-Reply-To: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462205.1332363812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462205.1332363812000.13801.1395930614156@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-220 stopped by Antoine Sabot-Durand.

> 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
>             Fix For: TBD
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 27 10:32:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 27 Mar 2014 10:32:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-428) Qualifying behavior for events and
 Observes is very different than qualifying beans and Injection Point
In-Reply-To: <JIRA.12535580.1395326740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535580.1395326740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535580.1395326740000.13818.1395930733175@jira02.app.mwc.hst.phx2.redhat.com>


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

Antoine Sabot-Durand updated CDI-428:
-------------------------------------

    Assignee: Antoine Sabot-Durand

    
> Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point
> -------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-428
>                 URL: https://issues.jboss.org/browse/CDI-428
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be more explicit that these behaves differently. The beginning of this possibility of confusion started with CDI-7. During CDI-422 resolution there was discussion about misunderstanding of these behavior.
> Everybody agree with the current way it's working but the specification obviously of precision about these differences. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Mar 27 10:32:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 27 Mar 2014 10:32:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-428) Qualifying behavior for events and
 Observes is very different than qualifying beans and Injection Point
In-Reply-To: <JIRA.12535580.1395326740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12535580.1395326740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535580.1395326740000.13819.1395930733214@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on CDI-428 started by Antoine Sabot-Durand.

> Qualifying behavior for events and Observes is very different than qualifying beans and Injection Point
> -------------------------------------------------------------------------------------------------------
>
>                 Key: CDI-428
>                 URL: https://issues.jboss.org/browse/CDI-428
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 1.1.Final
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> It should be more explicit that these behaves differently. The beginning of this possibility of confusion started with CDI-7. During CDI-422 resolution there was discussion about misunderstanding of these behavior.
> Everybody agree with the current way it's working but the specification obviously of precision about these differences. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Fri Mar 28 05:35:05 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 28 Mar 2014 10:35:05 +0100
Subject: [cdi-dev] Finishing MR
Message-ID: <5B051A0A-1711-4DEA-9F9C-68CE48472036@sabot-durand.net>

Hi all,


So we now have all the MR ticket processed. There?s still 3 ticket related PR pending on https://github.com/cdi-spec/cdi/pulls. We should close them by monday.
PR for CDI-428 and CDI-331 should be fast to review, so please take a few minutes to do it.

Mark, will you have time to work on CDI-392 before monday so we can close it ? I you don?t I?ll do it but let me know today please.

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

From struberg at yahoo.de  Fri Mar 28 18:18:41 2014
From: struberg at yahoo.de (Mark Struberg)
Date: Fri, 28 Mar 2014 22:18:41 +0000 (GMT)
Subject: [cdi-dev] JSR-392
Message-ID: <1396045121.93236.YahooMailNeo@web28904.mail.ir2.yahoo.com>

Hi!

I'm asking myself if forbiding various methods until AfterDeploymentValidation isn't a bit too tight.

It does of course make no sense to call getBeans, etc until AfterBeanDiscovery. 
But it could make sense to allow it IN AfterBeansDiscovery. Of course, adding beans in ABD would need to reset some resolver-caches maybe (depends on the actual container implementation). But at least it would make sense and would be pretty predictiable (in contrast to calling getBeans _during_ the class-scanning).


wdyt?

LieGrue,
strub
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140328/57c74447/attachment.html 

From issues at jboss.org  Sat Mar 29 05:34:12 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 29 Mar 2014 05:34:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17183.1396085652944@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-392:
-----------------------------------

After quite some discussion I suppose we also move the barrier from AfterDeploymentValidation to AfterBeanDiscovery as already suggested in CDI-274. 
The whole goal of this Exception is to prevent random behaviour during bean scanning. And this is perfectly guaranteed if we prevent those methods until AfterBeanDiscovery.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 29 05:50:12 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 29 Mar 2014 05:50:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17191.1396086612962@jira02.app.mwc.hst.phx2.redhat.com>


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

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

IMHO that's the best option [~struberg] : without it bean registration (or other meta data) based on existing bean is a total hell. So from the spec perspective I'm 100% for this. Now we really need to have input from [~pmuir], [~jharting] and [~mkouba] to be sure it's doable to implement that for the 1.2 RI (april 8th). 
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Sat Mar 29 10:35:09 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 29 Mar 2014 15:35:09 +0100
Subject: [cdi-dev] Mark proposed resolution for CDI-392
Message-ID: <781A3287-2926-466A-9632-A29493FE97BA@sabot-durand.net>

Hi guys,

As the deadline for this MR is approaching. I think we should all focus on the last important ticket of this Maintenance Release.

To make short resolution would allow all the bean manager method reserved for ADV to be used in ABD as well.

From a spec and user point of view, I?m 100 % for this approach. Now I understand this point was already discussed before in CDI-274  [1], but I really think we should reconsider this point to give ease extension development in 1.2.

thank for your feedback.


[1] https://issues.jboss.org/browse/CDI-274

Antoine


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140329/07e6aee6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140329/07e6aee6/attachment.bin 

From issues at jboss.org  Sat Mar 29 13:02:13 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Sat, 29 Mar 2014 13:02:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17233.1396112533167@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-392:
-------------------------------

I'm ok with this change, but I think we then need some warning on the method, that if called before ADV, you will not see the complete set of beans, as there is no guarantee about which order ABD methods are called in, and we add a FAQ indicating you can wreck startup times with this method, if used irresponsibly.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 29 13:10:13 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Sat, 29 Mar 2014 13:10:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17238.1396113013171@jira02.app.mwc.hst.phx2.redhat.com>


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

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

To be sure to understand [~pmuir], when talking about the non complete set of beans do you include beans discovered from AnnotatedType in this set or is it only bean added programmatically in ABD phase?

For the record, I did some tests : calling {{BeanManager.getBeans()}} fails in Weld 1.x with an empty retuned set, fails in Weld 2.x with an exception (as stated in the spec right now) and works in OWB.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 29 13:12:13 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Sat, 29 Mar 2014 13:12:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17241.1396113133010@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-392:
-------------------------------

The latter.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 29 14:38:12 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 29 Mar 2014 14:38:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17278.1396118292992@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-392:
-----------------------------------

Well, we have this behaviour throughout the whole container. It's also not guaranteed in which order different Extensions get the ProcessAnnotatedType called for example. Nor any other CDI Extension event. But this is fundamentally different to the bean-scanning randomness which is totally unpredictable.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 29 14:44:12 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Sat, 29 Mar 2014 14:44:12 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17285.1396118652939@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-392:
-------------------------------

Yes, but we don't allow access to this method on those events...
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 29 14:56:13 2014
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 29 Mar 2014 14:56:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17290.1396119373088@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Struberg commented on CDI-392:
-----------------------------------

Pete what I mean is that if one Extension changes the AnnotatedType for a class in PAT, and another Extension does as well, then depending on the order in which the Extensions get invoked they see different AnnotatedTypes. We cannot prevent such side effects. But this is fundamentally different to calling getBeans before the class scanning is finished (which really is nonsense and we are right in preventing this).

I've updated my pull request accordingly.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Mar 29 14:58:13 2014
From: issues at jboss.org (Pete Muir (JIRA))
Date: Sat, 29 Mar 2014 14:58:13 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of
 BeanManager can be called
In-Reply-To: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496686.1374070214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496686.1374070214000.17296.1396119493062@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on CDI-392:
-------------------------------

[~struberg] What I am saying is that people are *used* to getBeans() always returning the same thing, because it does most of the time (at runtime). So we should call out this difference. Start event order is always undefined, inside an event type.
                
> Clarify when the operations of BeanManager can be called
> --------------------------------------------------------
>
>                 Key: CDI-392
>                 URL: https://issues.jboss.org/browse/CDI-392
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Matus Abaffy
>            Assignee: Mark Struberg
>              Labels: CDI_spec_chge, Ready_to_fix
>             Fix For: 1.2 Proposed
>
>
> The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application."
> This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From antoine at sabot-durand.net  Mon Mar 31 08:12:17 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 31 Mar 2014 14:12:17 +0200
Subject: [cdi-dev] Final meeting about CDI-392
Message-ID: <8A555DAD-9AA0-4D24-AC91-7BBA6F497CA3@sabot-durand.net>

Hi all,

So this MR is nearly closed. But we still have this final ticket on which we don?t seem to agree. As we have to finished the MR today (theorically) I propose if you agree that we set our meeting sooner today to let us time to cleanly finish the work.

If it?s possible for you, I propose we meet one hour sooner at 5:00pm CEST / 4:00pm BST / 3:00pm GMT. I?d like to have the maximum participant so please let me know if you prefer this slot or one hour later as scheduled.

thx.

Antoine



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

From jharting at redhat.com  Mon Mar 31 08:16:10 2014
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 31 Mar 2014 14:16:10 +0200
Subject: [cdi-dev] Final meeting about CDI-392
In-Reply-To: <8A555DAD-9AA0-4D24-AC91-7BBA6F497CA3@sabot-durand.net>
References: <8A555DAD-9AA0-4D24-AC91-7BBA6F497CA3@sabot-durand.net>
Message-ID: <53395C8A.2050506@redhat.com>

I prefer the originally-scheduled time slot.

On 03/31/2014 02:12 PM, Antoine Sabot-Durand wrote:
> Hi all,
>
> So this MR is nearly closed. But we still have this final ticket on which we don't seem to agree. As we have to finished the MR today (theorically) I propose if you agree that we set our meeting sooner today to let us time to cleanly finish the work.
>
> If it's possible for you, I propose we meet one hour sooner at 5:00pm CEST / 4:00pm BST / 3:00pm GMT. I'd like to have the maximum participant so please let me know if you prefer this slot or one hour later as scheduled.
>
> thx.
>
> Antoine
>
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

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

From mkouba at redhat.com  Mon Mar 31 08:19:31 2014
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 31 Mar 2014 14:19:31 +0200
Subject: [cdi-dev] Final meeting about CDI-392
In-Reply-To: <53395C8A.2050506@redhat.com>
References: <8A555DAD-9AA0-4D24-AC91-7BBA6F497CA3@sabot-durand.net>
	<53395C8A.2050506@redhat.com>
Message-ID: <53395D53.9010705@redhat.com>

Unfortunately I can't make it today at 5:00pm... I will join one hour later.

Martin

Dne 31.3.2014 14:16, Jozef Hartinger napsal(a):
> I prefer the originally-scheduled time slot.
> 
> On 03/31/2014 02:12 PM, Antoine Sabot-Durand wrote:
>> Hi all,
>>
>> So this MR is nearly closed. But we still have this final ticket on which we don?t seem to agree. As we have to finished the MR today (theorically) I propose if you agree that we set our meeting sooner today to let us time to cleanly finish the work.
>>
>> If it?s possible for you, I propose we meet one hour sooner at 5:00pm CEST / 4:00pm BST / 3:00pm GMT. I?d like to have the maximum participant so please let me know if you prefer this slot or one hour later as scheduled.
>>
>> thx.
>>
>> Antoine
>>
>>
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 


From antoine at sabot-durand.net  Mon Mar 31 08:41:11 2014
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 31 Mar 2014 14:41:11 +0200
Subject: [cdi-dev] Final meeting about CDI-392
In-Reply-To: <53395D53.9010705@redhat.com>
References: <8A555DAD-9AA0-4D24-AC91-7BBA6F497CA3@sabot-durand.net>
	<53395C8A.2050506@redhat.com> <53395D53.9010705@redhat.com>
Message-ID: <6A368C41-060A-4E53-B0F1-E098E8D1BEC2@sabot-durand.net>

Ok forget it. We keep the 6:00pm schedule


Le 31 mars 2014 ? 14:19, Martin Kouba <mkouba at redhat.com> a ?crit :

> Unfortunately I can't make it today at 5:00pm... I will join one hour later.
> 
> Martin
> 
> Dne 31.3.2014 14:16, Jozef Hartinger napsal(a):
>> I prefer the originally-scheduled time slot.
>> 
>> On 03/31/2014 02:12 PM, Antoine Sabot-Durand wrote:
>>> Hi all,
>>> 
>>> So this MR is nearly closed. But we still have this final ticket on which we don?t seem to agree. As we have to finished the MR today (theorically) I propose if you agree that we set our meeting sooner today to let us time to cleanly finish the work.
>>> 
>>> If it?s possible for you, I propose we meet one hour sooner at 5:00pm CEST / 4:00pm BST / 3:00pm GMT. I?d like to have the maximum participant so please let me know if you prefer this slot or one hour later as scheduled.
>>> 
>>> thx.
>>> 
>>> Antoine
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
> 

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