From issues at jboss.org Wed Apr 2 05:17:13 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 2 Apr 2014 05:17:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-430) Revise the description of container lifecycle ordering during application initialization In-Reply-To: References: Message-ID: Martin Kouba created CDI-430: -------------------------------- Summary: Revise the description of container lifecycle ordering during application initialization Key: CDI-430 URL: https://issues.jboss.org/browse/CDI-430 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.1.Final Reporter: Martin Kouba E.g. it's not entirely clear when {{ProcessInjectionPoint}} if fired. Also it would be useful to mention {{ProcessBeanAttributes}} in bean discovery section. -- 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 Apr 3 03:52:08 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 3 Apr 2014 03:52:08 -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: References: Message-ID: [ https://issues.jboss.org/browse/CDI-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-425: ------------------------------------- Fix Version/s: 1.2 Proposed > 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 > Fix For: 1.2 Proposed > > > 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 Apr 3 03:52:08 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 3 Apr 2014 03:52:08 -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: References: Message-ID: [ https://issues.jboss.org/browse/CDI-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-425: ------------------------------------- Labels: CDI_api_chge CDI_spec_chge CDI_tck_chge Ready_to_fix (was: ) > 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 > Labels: CDI_api_chge, CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > 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 Thu Apr 3 04:30:45 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 3 Apr 2014 10:30:45 +0200 Subject: [cdi-dev] Order of lifecycle event in chapter 11 Message-ID: Hi all, Why the lifecycle events described in 11.5 are not introduced in their chronological order? And what is the order logic here, because I?d like to at least stress that there are not described in their actual sequence. 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/20140403/debe640e/attachment.bin From issues at jboss.org Thu Apr 3 04:45:20 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 3 Apr 2014 04:45:20 -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: References: Message-ID: [ https://issues.jboss.org/browse/CDI-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-425: ---------------------------------------- Assignee: Antoine Sabot-Durand > 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 > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > 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 Apr 3 04:47:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 3 Apr 2014 04:47:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-430) Revise the description of container lifecycle ordering during application initialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-430: ------------------------------------- Labels: CDI_spec_chge Ready_to_fix (was: ) > Revise the description of container lifecycle ordering during application initialization > ---------------------------------------------------------------------------------------- > > Key: CDI-430 > URL: https://issues.jboss.org/browse/CDI-430 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.Final > Reporter: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > > E.g. it's not entirely clear when {{ProcessInjectionPoint}} if fired. Also it would be useful to mention {{ProcessBeanAttributes}} in bean discovery section. -- 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 Apr 3 04:47:14 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 3 Apr 2014 04:47:14 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-430) Revise the description of container lifecycle ordering during application initialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-430: ------------------------------------- Fix Version/s: 1.2 Proposed > Revise the description of container lifecycle ordering during application initialization > ---------------------------------------------------------------------------------------- > > Key: CDI-430 > URL: https://issues.jboss.org/browse/CDI-430 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.Final > Reporter: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > E.g. it's not entirely clear when {{ProcessInjectionPoint}} if fired. Also it would be useful to mention {{ProcessBeanAttributes}} in bean discovery section. -- 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 Apr 3 04:47:14 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 3 Apr 2014 04:47:14 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-430) Revise the description of container lifecycle ordering during application initialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-430: ---------------------------------------- Assignee: Antoine Sabot-Durand > Revise the description of container lifecycle ordering during application initialization > ---------------------------------------------------------------------------------------- > > Key: CDI-430 > URL: https://issues.jboss.org/browse/CDI-430 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > E.g. it's not entirely clear when {{ProcessInjectionPoint}} if fired. Also it would be useful to mention {{ProcessBeanAttributes}} in bean discovery section. -- 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 Apr 3 04:51:15 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 3 Apr 2014 04:51:15 -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: References: Message-ID: [ https://issues.jboss.org/browse/CDI-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-425 started by Antoine Sabot-Durand. > 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 > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > 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 Thu Apr 3 05:37:47 2014 From: pmuir at redhat.com (Pete Muir) Date: Thu, 3 Apr 2014 10:37:47 +0100 Subject: [cdi-dev] Order of lifecycle event in chapter 11 In-Reply-To: References: Message-ID: They basically are in chronological order, but in two groupings: * Group 1: Global lifecycle events - those that are fired once * Group 2: Discovery events - those that are fired once per thing processed I?m not sure interleaving them would really make things clearer. It would be better to describe the ordering as is. On 3 Apr 2014, at 09:30, Antoine Sabot-Durand wrote: > Hi all, > > Why the lifecycle events described in 11.5 are not introduced in their chronological order? And what is the order logic here, because I?d like to at least stress that there are not described in their actual sequence. > > Antoine From antoine at sabot-durand.net Thu Apr 3 05:43:43 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 3 Apr 2014 11:43:43 +0200 Subject: [cdi-dev] Order of lifecycle event in chapter 11 In-Reply-To: References: Message-ID: <53052C3F-B5AB-4069-B4CB-B0DA50F491CE@sabot-durand.net> Yes : no reordering in 11.5 now. We have the actual chronological order in 12.2 . I just wanted to introduce the ordering logic in 11.5 to avoid people assuming it?s the chronological order and perhaps be more explicit on the 12.2 pointer in 11.5 introduction. Thanks Antoine Le 3 avr. 2014 ? 11:37, Pete Muir a ?crit : > They basically are in chronological order, but in two groupings: > > * Group 1: Global lifecycle events - those that are fired once > * Group 2: Discovery events - those that are fired once per thing processed > > I?m not sure interleaving them would really make things clearer. It would be better to describe the ordering as is. > > On 3 Apr 2014, at 09:30, Antoine Sabot-Durand wrote: > >> Hi all, >> >> Why the lifecycle events described in 11.5 are not introduced in their chronological order? And what is the order logic here, because I?d like to at least stress that there are not described in their actual sequence. >> >> 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/20140403/d5a59795/attachment.bin From issues at jboss.org Thu Apr 3 06:03:13 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 3 Apr 2014 06:03:13 -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: References: Message-ID: [ https://issues.jboss.org/browse/CDI-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12958824#comment-12958824 ] Jozef Hartinger commented on CDI-425: ------------------------------------- for AfterTypeDiscovery we should probably not only guard AfterTypeDiscovery methods but also write operations on the interceptor/decorator/alternative lists. > 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 > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > 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 Fri Apr 4 03:23:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 4 Apr 2014 03:23:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-430) Revise the description of container lifecycle ordering during application initialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-430: ------------------------------------- Comment: was deleted (was: https://github.com/cdi-spec/cdi/pull/229) > Revise the description of container lifecycle ordering during application initialization > ---------------------------------------------------------------------------------------- > > Key: CDI-430 > URL: https://issues.jboss.org/browse/CDI-430 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > E.g. it's not entirely clear when {{ProcessInjectionPoint}} if fired. Also it would be useful to mention {{ProcessBeanAttributes}} in bean discovery section. -- 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 Apr 4 06:17:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 4 Apr 2014 06:17:13 -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: References: Message-ID: [ https://issues.jboss.org/browse/CDI-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12959224#comment-12959224 ] Antoine Sabot-Durand commented on CDI-425: ------------------------------------------ Right [~jharting], I updated the Javadoc to add this limitation 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 > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > 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 Fri Apr 4 11:50:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 4 Apr 2014 11:50:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-385) ProcessObserverMethod is different btw spec and API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-385: ------------------------------------- Fix Version/s: 1.2 Proposed > ProcessObserverMethod is different btw spec and API > --------------------------------------------------- > > Key: CDI-385 > URL: https://issues.jboss.org/browse/CDI-385 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.PFD > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.2 Proposed > > > As stated in CDI-88 the spec and API is different for ProcessObserverMethod. > In the spec there is a method > public AnnotatedParameter getAnnotatedEventParameter(); > but in the API there is > AnnotatedMethod getAnnotatedMethod(); > which imo makes much more sense anyway. > Thus we should amend the spec wording finally. -- 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 Apr 4 11:50:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 4 Apr 2014 11:50:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-385) ProcessObserverMethod is different btw spec and API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-385: ---------------------------------------- Assignee: Antoine Sabot-Durand > ProcessObserverMethod is different btw spec and API > --------------------------------------------------- > > Key: CDI-385 > URL: https://issues.jboss.org/browse/CDI-385 > 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_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As stated in CDI-88 the spec and API is different for ProcessObserverMethod. > In the spec there is a method > public AnnotatedParameter getAnnotatedEventParameter(); > but in the API there is > AnnotatedMethod getAnnotatedMethod(); > which imo makes much more sense anyway. > Thus we should amend the spec wording finally. -- 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 Apr 4 11:50:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 4 Apr 2014 11:50:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-385) ProcessObserverMethod is different btw spec and API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-385: ------------------------------------- Labels: CDI_spec_chge Ready_to_fix (was: ) > ProcessObserverMethod is different btw spec and API > --------------------------------------------------- > > Key: CDI-385 > URL: https://issues.jboss.org/browse/CDI-385 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.PFD > Reporter: Mark Struberg > Priority: Critical > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As stated in CDI-88 the spec and API is different for ProcessObserverMethod. > In the spec there is a method > public AnnotatedParameter getAnnotatedEventParameter(); > but in the API there is > AnnotatedMethod getAnnotatedMethod(); > which imo makes much more sense anyway. > Thus we should amend the spec wording finally. -- 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 Apr 4 11:50:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 4 Apr 2014 11:50:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-385) ProcessObserverMethod is different btw spec and API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-385 started by Antoine Sabot-Durand. > ProcessObserverMethod is different btw spec and API > --------------------------------------------------- > > Key: CDI-385 > URL: https://issues.jboss.org/browse/CDI-385 > 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_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As stated in CDI-88 the spec and API is different for ProcessObserverMethod. > In the spec there is a method > public AnnotatedParameter getAnnotatedEventParameter(); > but in the API there is > AnnotatedMethod getAnnotatedMethod(); > which imo makes much more sense anyway. > Thus we should amend the spec wording finally. -- 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 Apr 7 02:34:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 7 Apr 2014 02:34:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-392: ---------------------------------------- Assignee: Antoine Sabot-Durand (was: Mark Struberg) > 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: Antoine Sabot-Durand > 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 Apr 7 05:34:38 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 7 Apr 2014 11:34:38 +0200 Subject: [cdi-dev] Please review new PR for CDI-392 Message-ID: <55370A5F-4934-4CA6-9C18-F340F82A99C5@sabot-durand.net> Hi all, Just posted new Pull Request for our final ticket. Please take time to review it ASAP, so we could close the MR tonight. https://github.com/cdi-spec/cdi/pull/232 Thanks a lot. 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/20140407/ce0bef63/attachment.bin From issues at jboss.org Mon Apr 7 07:00:13 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 7 Apr 2014 07:00:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-430) Revise the description of container lifecycle ordering during application initialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reopened CDI-430: --------------------------------- Sorry for late review. There are several problems with the change: 1) Determining enabled alternatives, interceptors and decorators 12.4.3 has two bullets starting with: "if the class is an enabled bean, interceptor or decorator, create ..." and then the spec says: "Then, the container determines which alternatives, interceptors and decorators are enabled ..." The ordering here is clearly wrong (here since enabled beans, interceptors and decorators need to actually be determined for ProcessBean / ProcessBeanAttributes) 2) Strict ordering The current ordering rules are way too strict. For example, the following ordering is required: - create InjectionTarget, then - fire ProcessInjectionTarget, and later - create a Bean object However, this cannot be implemented since an observer for ProcessInjectionTarget may call: ProcessInjectionTarget.getInjectionTarget().getInjectionPoints().getBean() Since the Bean object has not been created yet the container cannot fulfil the contract. Same for ProcessInjectionPoint. 3) ProcessInjectionPoint should also be fired for InjectionPoints of producers/observers. The CDI 1.1 wording does not make that explicit. The current CDI-430 solution does not reflect this either within the new event ordering. > Revise the description of container lifecycle ordering during application initialization > ---------------------------------------------------------------------------------------- > > Key: CDI-430 > URL: https://issues.jboss.org/browse/CDI-430 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > E.g. it's not entirely clear when {{ProcessInjectionPoint}} if fired. Also it would be useful to mention {{ProcessBeanAttributes}} in bean discovery section. -- 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 Apr 7 08:02:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 7 Apr 2014 08:02:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-430) Revise the description of container lifecycle ordering during application initialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-430 started by Antoine Sabot-Durand. > Revise the description of container lifecycle ordering during application initialization > ---------------------------------------------------------------------------------------- > > Key: CDI-430 > URL: https://issues.jboss.org/browse/CDI-430 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > E.g. it's not entirely clear when {{ProcessInjectionPoint}} if fired. Also it would be useful to mention {{ProcessBeanAttributes}} in bean discovery section. -- 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 Apr 8 03:35:21 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 8 Apr 2014 09:35:21 +0200 Subject: [cdi-dev] Last review on CDI-430 PR Message-ID: Hi all, I integrated Pete comments and switch filtering and type discovery parts. Please review these small last changes ASAP [1]. [1] https://github.com/cdi-spec/cdi/pull/233 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/20140408/02fb2303/attachment.bin From issues at jboss.org Wed Apr 9 11:34:13 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 9 Apr 2014 11:34:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-431) BeanManager Javadoc inconsistency In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-431: ----------------------------------- Summary: BeanManager Javadoc inconsistency Key: CDI-431 URL: https://issues.jboss.org/browse/CDI-431 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Reporter: Jozef Hartinger Assignee: Antoine Sabot-Durand Fix For: 1.2 Proposed https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L78 vs https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L211 -- 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 Apr 10 05:00:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 10 Apr 2014 05:00:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-431) BeanManager Javadoc inconsistency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-431: ------------------------------------- Labels: Ready_to_fix (was: ) > BeanManager Javadoc inconsistency > --------------------------------- > > Key: CDI-431 > URL: https://issues.jboss.org/browse/CDI-431 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L78 > vs > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L211 -- 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 Apr 10 05:00:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 10 Apr 2014 05:00:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-431) BeanManager Javadoc inconsistency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-431 started by Antoine Sabot-Durand. > BeanManager Javadoc inconsistency > --------------------------------- > > Key: CDI-431 > URL: https://issues.jboss.org/browse/CDI-431 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L78 > vs > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L211 -- 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 Apr 10 05:04:13 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 10 Apr 2014 05:04:13 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-431) BeanManager Javadoc inconsistency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-431. -------------------------------------- Resolution: Done > BeanManager Javadoc inconsistency > --------------------------------- > > Key: CDI-431 > URL: https://issues.jboss.org/browse/CDI-431 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L78 > vs > https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/inject/spi/BeanManager.java#L211 -- 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 Apr 11 10:17:49 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 11 Apr 2014 16:17:49 +0200 Subject: [cdi-dev] CDI 1.2 release progress Message-ID: Hi all, Just to keep you posted on 1.2 release evolution. Right now we are in the ballot period which ends on april 14th. There should be no problem to have a favorable result at the end of the ballot (an MR was never rejected in the JCP so far). Meanwhile there?s a lot of work to do for Weld team to finish RI, TCK and WildFly patch to release them next week. Jozef helped me this morning to release CDI 1.2 api. Artifacts are now staging in JBoss repo [1]. I published spec documentation in html [2] and pdf [3] and 1.2 javadoc as well [4]. There?ll be publicly released on tuesday or wednesday depending when JCP send us the green light. Antoine [1] https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3043/ [2] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html [3] http://docs.jboss.org/cdi/spec/1.2/cdi-spec-1.2.pdf [4] http://docs.jboss.org/cdi/api/1.2 -------------- 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/20140411/68a99d42/attachment.bin From mkouba at redhat.com Wed Apr 16 07:08:55 2014 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 16 Apr 2014 13:08:55 +0200 Subject: [cdi-dev] AfterBeanDiscovery in the light of CDI-392 Message-ID: <534E64C7.2050808@redhat.com> Hi all, I see an inconsistency between the resolution of CDI-392 and the current wording of "11.5.3. AfterBeanDiscovery event". addBean(): "Fires an event of type ProcessBean containing the given Bean and then registers the Bean with the container, thereby making it available for injection into other beans. The given Bean may implement Interceptor or Decorator." On the other hand BeanManager.getBeans() javadoc: "Note that when called during invocation of an AfterBeanDiscovery event observer, this method will only return beans discovered by the container before the AfterBeanDiscovery event is fired." It seems ProcessBean should be fired and the bean should be registred when addBean() is called BUT in the same time it should not be available via BeanManager.getBeans() until all AfterBeanDiscovery observers are processed. The same applies to observer methods. Weld 2.2.0.Final delays the ProcessBean/registration until all AfterBeanDiscovery observers are processed (note that it's not backwards compatible). I believe this is correct. If so, the AfterBeanDiscovery event description should be clarified. Otherwise the RI must be changed (and I'm afraid it wouldn't be that trivial). -- Martin Kouba Software Engineer Red Hat, Czech Republic From jharting at redhat.com Wed Apr 16 09:17:06 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 16 Apr 2014 15:17:06 +0200 Subject: [cdi-dev] AfterBeanDiscovery in the light of CDI-392 In-Reply-To: <534E64C7.2050808@redhat.com> References: <534E64C7.2050808@redhat.com> Message-ID: <534E82D2.6010807@redhat.com> Queuing ABD operations and applying them once all ABD observers are finished was part of the solution for CDI-392 however it seems that this part is not reflected within the specification :-/ On 04/16/2014 01:08 PM, Martin Kouba wrote: > Hi all, > > I see an inconsistency between the resolution of CDI-392 and the current > wording of "11.5.3. AfterBeanDiscovery event". > > addBean(): "Fires an event of type ProcessBean containing the given Bean > and then registers the Bean with the container, thereby making it > available for injection into other beans. The given Bean may implement > Interceptor or Decorator." > > On the other hand BeanManager.getBeans() javadoc: > "Note that when called during invocation of an AfterBeanDiscovery event > observer, this method will only return beans discovered by the container > before the AfterBeanDiscovery event is fired." > > It seems ProcessBean should be fired and the bean should be registred > when addBean() is called BUT in the same time it should not be available > via BeanManager.getBeans() until all AfterBeanDiscovery observers are > processed. > > The same applies to observer methods. > > Weld 2.2.0.Final delays the ProcessBean/registration until all > AfterBeanDiscovery observers are processed (note that it's not backwards > compatible). I believe this is correct. If so, the AfterBeanDiscovery > event description should be clarified. Otherwise the RI must be changed > (and I'm afraid it wouldn't be that trivial). > > From antoine at sabot-durand.net Wed Apr 16 16:30:25 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 16 Apr 2014 22:30:25 +0200 Subject: [cdi-dev] AfterBeanDiscovery in the light of CDI-392 In-Reply-To: <534E82D2.6010807@redhat.com> References: <534E64C7.2050808@redhat.com> <534E82D2.6010807@redhat.com> Message-ID: <9CA50E7E-D981-44BA-8810-62B4564637B5@sabot-durand.net> Martin, You?re right, we should clarify this point. Do we agree that all the ProcessBean event should be queued for beans added during ABD ? Antoine Le 16 avr. 2014 ? 15:17, Jozef Hartinger a ?crit : > Queuing ABD operations and applying them once all ABD observers are > finished was part of the solution for CDI-392 however it seems that this > part is not reflected within the specification :-/ > > On 04/16/2014 01:08 PM, Martin Kouba wrote: >> Hi all, >> >> I see an inconsistency between the resolution of CDI-392 and the current >> wording of "11.5.3. AfterBeanDiscovery event". >> >> addBean(): "Fires an event of type ProcessBean containing the given Bean >> and then registers the Bean with the container, thereby making it >> available for injection into other beans. The given Bean may implement >> Interceptor or Decorator." >> >> On the other hand BeanManager.getBeans() javadoc: >> "Note that when called during invocation of an AfterBeanDiscovery event >> observer, this method will only return beans discovered by the container >> before the AfterBeanDiscovery event is fired." >> >> It seems ProcessBean should be fired and the bean should be registred >> when addBean() is called BUT in the same time it should not be available >> via BeanManager.getBeans() until all AfterBeanDiscovery observers are >> processed. >> >> The same applies to observer methods. >> >> Weld 2.2.0.Final delays the ProcessBean/registration until all >> AfterBeanDiscovery observers are processed (note that it's not backwards >> compatible). I believe this is correct. If so, the AfterBeanDiscovery >> event description should be clarified. Otherwise the RI must be changed >> (and I'm afraid it wouldn't be that trivial). >> >> > > _______________________________________________ > 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/20140416/6c77ceb2/attachment.bin From issues at jboss.org Thu Apr 17 03:50:33 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Apr 2014 03:50:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-432) AfterBeanDiscovery "addBean" and "addObserverMethod" operations should be queued and applied after all ABD observers are notified In-Reply-To: References: Message-ID: Martin Kouba created CDI-432: -------------------------------- Summary: AfterBeanDiscovery "addBean" and "addObserverMethod" operations should be queued and applied after all ABD observers are notified Key: CDI-432 URL: https://issues.jboss.org/browse/CDI-432 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Martin Kouba This was originally part of the solution for CDI-392. -- 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 Apr 17 03:52:33 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 17 Apr 2014 03:52:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-432) AfterBeanDiscovery "addBean" and "addObserverMethod" operations should be queued and applied after all ABD observers are notified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12962442#comment-12962442 ] Martin Kouba commented on CDI-432: ---------------------------------- http://lists.jboss.org/pipermail/cdi-dev/2014-April/005034.html > AfterBeanDiscovery "addBean" and "addObserverMethod" operations should be queued and applied after all ABD observers are notified > --------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-432 > URL: https://issues.jboss.org/browse/CDI-432 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > This was originally part of the solution for CDI-392. -- 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 Apr 17 19:42:33 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 17 Apr 2014 19:42:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-433) AdminEvent example has redundant qualifiers. In-Reply-To: References: Message-ID: John Ament created CDI-433: ------------------------------ Summary: AdminEvent example has redundant qualifiers. Key: CDI-433 URL: https://issues.jboss.org/browse/CDI-433 Project: CDI Specification Issues Issue Type: Clarification Reporter: John Ament Priority: Minor In the CDI 1.2 spec, the following text appears: For example, this injected Event has specified type LoggedInEvent and specified qualifier @Admin: {{@Inject @Admin Event any;}} The select() method returns a child Event for a given specified type and additional specified qualifiers. If no specified type is given, the specified type is the same as the parent. For example, this child Event has required type AdminLoggedInEvent and additional specified qualifier {{@Admin}}: {noformat} Event admin = any.select( AdminLoggedInEvent.class, new AdminQualifier() ); {noformat} The problem is that the injection point any already is qualified @Admin, so the use is duplicate here. I believe the intention was that the injection point would read {{@Inject Event any;}} -- 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 Apr 17 19:42:34 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 17 Apr 2014 19:42:34 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-433) AdminEvent example has redundant qualifiers. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ament updated CDI-433: --------------------------- Affects Version/s: 1.2.Final > AdminEvent example has redundant qualifiers. > -------------------------------------------- > > Key: CDI-433 > URL: https://issues.jboss.org/browse/CDI-433 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: John Ament > Priority: Minor > > In the CDI 1.2 spec, the following text appears: > For example, this injected Event has specified type LoggedInEvent and specified qualifier @Admin: > {{@Inject @Admin Event any;}} > The select() method returns a child Event for a given specified type and additional specified qualifiers. If no specified type is given, the specified type is the same as the parent. > For example, this child Event has required type AdminLoggedInEvent and additional specified qualifier {{@Admin}}: > {noformat} > Event admin = any.select( > AdminLoggedInEvent.class, > new AdminQualifier() ); > {noformat} > The problem is that the injection point any already is qualified @Admin, so the use is duplicate here. I believe the intention was that the injection point would read > {{@Inject Event any;}} -- 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 Apr 18 09:58:33 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 18 Apr 2014 09:58:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated In-Reply-To: References: Message-ID: Martin Kouba created CDI-434: -------------------------------- Summary: AfterTypeDiscovery javadoc outdated Key: CDI-434 URL: https://issues.jboss.org/browse/CDI-434 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Martin Kouba {quote} *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list {quote} vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29 The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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 Apr 22 05:06:33 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 22 Apr 2014 05:06:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-435) cdi-spec.org/faq outdated In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-435: ----------------------------------- Summary: cdi-spec.org/faq outdated Key: CDI-435 URL: https://issues.jboss.org/browse/CDI-435 Project: CDI Specification Issues Issue Type: Bug Reporter: Jozef Hartinger Assignee: Antoine Sabot-Durand Frequently asked questions at http://www.cdi-spec.org/faq/ are outdated - mostly in sync with CDI 1.0 or CDI 1.1. -- 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 Apr 25 06:24:33 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 25 Apr 2014 06:24:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba reassigned CDI-434: -------------------------------- Assignee: Martin Kouba > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29 > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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 Apr 25 08:42:34 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 25 Apr 2014 08:42:34 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963824#comment-12963824 ] Martin Kouba commented on CDI-434: ---------------------------------- The spec is also not clear whether "the ordered list" means ascending or descending order. I believe the intent was to have it sorted by priority in ascending order. > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29 > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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 Apr 25 10:42:34 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 25 Apr 2014 10:42:34 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963869#comment-12963869 ] Martin Kouba commented on CDI-434: ---------------------------------- Note that for alternatives the following paragraph is misleading: {quote} Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. The container must use the final values of these collections, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. {quote} The problem is that the priority value of an alternative is used during resolution and thus the ordering of the alternatives collection does not matter. The container may use the final values to identify removed/deselected alternatives and to declare a new selected alternative for an application - without priority value. However, it must preserve the original priorities to perform resolution correctly. > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29 > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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 Apr 29 04:32:33 2014 From: issues at jboss.org (Matus Abaffy (JIRA)) Date: Tue, 29 Apr 2014 04:32:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-436) Specialization requirements do not allow parameterized types to be specialized In-Reply-To: References: Message-ID: Matus Abaffy created CDI-436: -------------------------------- Summary: Specialization requirements do not allow parameterized types to be specialized Key: CDI-436 URL: https://issues.jboss.org/browse/CDI-436 Project: CDI Specification Issues Issue Type: Bug Reporter: Matus Abaffy {quote} Formally, a bean X is said to specialize another bean Y if either: ... 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} The tricky part about having all the bean types is that two parameterized types might not equal (in the java sense) even though they "are the same". That's because of the inequality between type variables. Example: {code} class Foo {} {code} {code} class Bar extends Foo {} {code} Bar seems to have all the bean types of Foo, but it does not. Foo from class Bar is not equal to Foo from class Foo. I suppose the intention of the spec. was that if bean X specializes bean Y, then for each bean type T of Y, X must have a bean type U that is assignable from T. -- 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 Apr 30 04:02:33 2014 From: issues at jboss.org (Matus Abaffy (JIRA)) Date: Wed, 30 Apr 2014 04:02:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-436) Specialization requirements do not allow parameterized types to be specialized In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matus Abaffy updated CDI-436: ----------------------------- Affects Version/s: 1.2.Final > Specialization requirements do not allow parameterized types to be specialized > ------------------------------------------------------------------------------ > > Key: CDI-436 > URL: https://issues.jboss.org/browse/CDI-436 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Matus Abaffy > > {quote} > Formally, a bean X is said to specialize another bean Y if either: > ... > 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} > The tricky part about having all the bean types is that two parameterized types might not equal (in the java sense) even though they "are the same". That's because of the inequality between type variables. Example: > {code} > class Foo {} > {code} > {code} > class Bar extends Foo {} > {code} > Bar seems to have all the bean types of Foo, but it does not. Foo from class Bar is not equal to Foo from class Foo. > I suppose the intention of the spec. was that if bean X specializes bean Y, then for each bean type T of Y, X must have a bean type U that is assignable from T. -- 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 Apr 30 04:18:33 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 30 Apr 2014 04:18:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly In-Reply-To: References: Message-ID: Martin Kouba created CDI-437: -------------------------------- Summary: The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly Key: CDI-437 URL: https://issues.jboss.org/browse/CDI-437 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Martin Kouba {quote} Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. {quote} However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. The container can either: * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering The first option seems to be less harmful. -- This message 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 Apr 30 04:22:33 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 30 Apr 2014 04:22:33 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964610#comment-12964610 ] Martin Kouba commented on CDI-434: ---------------------------------- I've created a separate issue for the problem mentioned in the last comment - see CDI-437. > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDiscovery.html#getAlternatives%28%29 > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- 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 Apr 30 05:54:34 2014 From: issues at jboss.org (Matus Abaffy (JIRA)) Date: Wed, 30 Apr 2014 05:54:34 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-436) Specialization requirements do not allow parameterized types to be specialized In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964631#comment-12964631 ] Matus Abaffy commented on CDI-436: ---------------------------------- Actually, if X<...> specializes Y<...>, then bean X cannot have some "more general" bean type than bean Y (otherwise it could not extend it, or override it in the case of producer methods). So if X has a bean type U that is assignable from (more general than) bean type T of Y, then U and T must really be the same. Just not necessarily equal in the java sense. > Specialization requirements do not allow parameterized types to be specialized > ------------------------------------------------------------------------------ > > Key: CDI-436 > URL: https://issues.jboss.org/browse/CDI-436 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Matus Abaffy > > {quote} > Formally, a bean X is said to specialize another bean Y if either: > ... > 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} > The tricky part about having all the bean types is that two parameterized types might not equal (in the java sense) even though they "are the same". That's because of the inequality between type variables. Example: > {code} > class Foo {} > {code} > {code} > class Bar extends Foo {} > {code} > Bar seems to have all the bean types of Foo, but it does not. Foo from class Bar is not equal to Foo from class Foo. > I suppose the intention of the spec. was that if bean X specializes bean Y, then for each bean type T of Y, X must have a bean type U that is assignable from T. -- 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 arne.limburg at openknowledge.de Wed Apr 30 15:32:35 2014 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Wed, 30 Apr 2014 19:32:35 +0000 Subject: [cdi-dev] Events and Type Variables in CDI 1.1 Message-ID: Hi, I found an issue in either the spec or the tck, which I would like to discuss: The TCK-Test org.jboss.cdi.tck.tests.event.fires.FireEventTest.testTypeVariableEventTypeFails uses the following bean to fire an event by calling the method fireWithTypeVariable() public class Bar { @Inject private Event> event; public void fireWithTypeVariable() { event.fire(new Foo()); } } The TCK expects this test to fail because of the type variable in the instance created by new Foo() However, the spec states in 10.3.1 ?If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types.? Imho in this case the container is able to resolve T to "? extends Number? and the spec does not prohibit an event to have a wildcard type. So since T is not unresolvable, this test case should not expect the container to throw an exception. If we consider T not to be resolved, because it resolves to a wildcard type, we should mention this somewhere in the spec. Or am I missing something? Cheers, Arne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140430/dc39b4af/attachment.html