From issues at jboss.org Wed Feb 1 07:05:01 2017 From: issues at jboss.org (Samba Siva Rao Kolusu (JIRA)) Date: Wed, 1 Feb 2017 07:05:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow de-registration of CDI beans at run time, through API In-Reply-To: References: Message-ID: Samba Siva Rao Kolusu created CDI-682: ----------------------------------------- Summary: Allow de-registration of CDI beans at run time, through API Key: CDI-682 URL: https://issues.jboss.org/browse/CDI-682 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans, Events, Interceptors Affects Versions: 1.2.Final Reporter: Samba Siva Rao Kolusu -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 07:13:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 1 Feb 2017 07:13:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow de-registration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356202#comment-13356202 ] Tomas Remes commented on CDI-682: --------------------------------- Hi [~saasira] Could you be please more specific? > Allow de-registration of CDI beans at run time, through API > ----------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 07:15:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 1 Feb 2017 07:15:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow de-registration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356204#comment-13356204 ] Matej Novotny commented on CDI-682: ----------------------------------- Also de-registration sounds like an impossible feat because of the static nature of CDI. Things are done at bootstrap and they stay that way in application runtime. Imagine what would happen if you had a {{@Specializes}} bean and tried to de-register that one at runtime. > Allow de-registration of CDI beans at run time, through API > ----------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 07:16:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 1 Feb 2017 07:16:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow de-registration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356204#comment-13356204 ] Matej Novotny edited comment on CDI-682 at 2/1/17 7:15 AM: ----------------------------------------------------------- Also de-registration sounds like an impossible feat because of the static nature of CDI. Things are done at bootstrap and they stay that way during application runtime. Imagine what would happen if you had a {{@Specializes}} bean and tried to de-register that one at runtime. Furthermore, this would result in weird behaviour if you, say, de-register a session scoped bean during active session. was (Author: manovotn): Also de-registration sounds like an impossible feat because of the static nature of CDI. Things are done at bootstrap and they stay that way in application runtime. Imagine what would happen if you had a {{@Specializes}} bean and tried to de-register that one at runtime. > Allow de-registration of CDI beans at run time, through API > ----------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 07:18:00 2017 From: issues at jboss.org (Samba Siva Rao Kolusu (JIRA)) Date: Wed, 1 Feb 2017 07:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow de-registration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samba Siva Rao Kolusu updated CDI-682: -------------------------------------- Description: much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) also provide API BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart > Allow de-registration of CDI beans at run time, through API > ----------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 07:18:00 2017 From: issues at jboss.org (Samba Siva Rao Kolusu (JIRA)) Date: Wed, 1 Feb 2017 07:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samba Siva Rao Kolusu updated CDI-682: -------------------------------------- Summary: Allow unregistration of CDI beans at run time, through API (was: Allow de-registration of CDI beans at run time, through API) > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 07:32:00 2017 From: issues at jboss.org (Samba Siva Rao Kolusu (JIRA)) Date: Wed, 1 Feb 2017 07:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356219#comment-13356219 ] Samba Siva Rao Kolusu commented on CDI-682: ------------------------------------------- such activities are generally performed during maintenance window; hence need not worry about concurrency (what if customer is accessing a page that is using a CDI bean to fetch/post/process data, etc). static nature of CDI is not a technological limitation; it was only implemented 'thus far' for its first version. when we plan to take it to next level, we can always enhance it to add valuable features, especially when not too difficult to implement. All that is needed to implement these is expose API publicly so that we can call BeanManager.register(XYZBean.class) when we think that XYZBean.class is ready in the class path. similarly, expose public API so that we can call BeanManager.unregister(XYZBean.class) when we think we will be removing that XYZBean.class from the classpath. @Specializes means that the specialized bean class has a dependency on the bean being removed, so we have two options - remove the specialized as well, or prevent the bean from being unregistered - which may vary depending on application concerns. let the application developers handle the consequences by providing appropriate Events. "de-registration sounds like an impossible feat because of the static nature of CDI. Things are done at bootstrap and they stay that way during application runtime" ---- just because it was done this way 'in the beginning', does not mean we have to stay that way forever, should we? > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 07:42:00 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Wed, 1 Feb 2017 07:42:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356226#comment-13356226 ] Tomas Remes commented on CDI-682: --------------------------------- Feel free to propose some API proposal. Just note that bean removal basically means bean graph reconstruction because you need to check all the related injection points, related interceptors, decorators, etc. of the given bean so it basically means the same as CDI container restart IMO. > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 08:11:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 1 Feb 2017 08:11:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356255#comment-13356255 ] Antoine Sabot-Durand commented on CDI-682: ------------------------------------------ [~saasira] as you say, there is no technical reason to forbid registering or unregistering of Beans at runtime. We are more here on a philosophical reason: CDI was designed to create the bean graph once at boot time giving us performance and limiting runtime exception on DI to the maximum. This ticket or CDI-114 would greatly change CDI spirit making the spec far more complicated, so the EG was not in favour of such an approach. > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Siva Rao Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 10:53:00 2017 From: issues at jboss.org (Samba Kolusu (JIRA)) Date: Wed, 1 Feb 2017 10:53:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356778#comment-13356778 ] Samba Kolusu commented on CDI-682: ---------------------------------- "CDI was designed to create the bean graph once at boot time giving us performance and limiting runtime exception on DI to the maximum." -- i agree that was primary purpose of CDI, and that is achieved with excellence. now, having reached a stable state of the stated goal, can't we scale to the next step? protective defaults are good for most of the cases, but it is those few cases which require adaptive flexibility to build "extra-mile" features. EJB provides UserTransaction besides Container Managed Transactions -- to let the developers handle specialized situations that cannot used CMT (of course, EJBContainer is also monolithic). for a start, you can leave the responsibility of validating bean-injection-point-interceptor-decorator-qualifier graph to the application developer; after all, it is his/her code is triggering registration/unregistration of beans at runtime, so he/she should be having all the details while processing bean registration events. let the application developer face the consequences of using this API wrongly with well defined exceptions. or if it is possible to validate the bean graph in CDI container itself (if no time or resource constraints), that would be a great thing to happen to Java EE -- a modular web application platform that was missing for several years. at least we should learn from the success of PHP CMS like Drupal which were modular for more than a decade now. Apache Deltaspike (a CDI implementation) provides some convenient API, though not to the extent of individual beans. ContextControl contextControl = BeanProvider.getContextualReference(ContextControl.class); // stoping the request context will dispose all the @RequestScoped beans contextControl.stopContext(RequestScoped.class); // and now restarting the request context, request scoped beans get reloaded by CDI container contextControl.startContext(RequestScoped.class); possibly some time in future they may also implement BeanManager.register(XYZBean.class), and BeanManager.unregister(XYZBean.class) on popular demand. why lose the opportunity ( before the next CDI spec) to make this a standard feature (that may be made optional for CDI containers to implement or ignore)? as a side note : even the API for starting & stopping CDI container is non-standard and left to implementations. > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 10:55:00 2017 From: issues at jboss.org (Samba Kolusu (JIRA)) Date: Wed, 1 Feb 2017 10:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356778#comment-13356778 ] Samba Kolusu edited comment on CDI-682 at 2/1/17 10:54 AM: ----------------------------------------------------------- "CDI was designed to create the bean graph once at boot time giving us performance and limiting runtime exception on DI to the maximum." -- i agree that was primary purpose of CDI, and that is achieved with excellence. now, having reached a stable state of the stated goal, can't we scale to the next step? protective defaults are good for most of the cases, but it is those few cases which require adaptive flexibility to build "extra-mile" features. EJB provides UserTransaction besides Container Managed Transactions -- to let the developers handle specialized situations that cannot used CMT (of course, EJBContainer is also monolithic). for a start, you can leave the responsibility of validating bean-injection-point-interceptor-decorator-qualifier graph to the application developer; after all, it is his/her code is triggering registration/unregistration of beans at runtime, so he/she should be having all the details while processing bean registration requests (on installation of a module, for example). let the application developer face the consequences of using this API wrongly with well defined exceptions. or if it is possible to validate the bean graph in CDI container itself (if no time or resource constraints), that would be a great thing to happen to Java EE -- a modular web application platform that was missing for several years. at least we should learn from the success of PHP CMS like Drupal which were modular for more than a decade now. Apache Deltaspike (a CDI implementation) provides some convenient API, though not to the extent of individual beans. ContextControl contextControl = BeanProvider.getContextualReference(ContextControl.class); // stoping the request context will dispose all the @RequestScoped beans contextControl.stopContext(RequestScoped.class); // and now restarting the request context, request scoped beans get reloaded by CDI container contextControl.startContext(RequestScoped.class); possibly some time in future they may also implement BeanManager.register(XYZBean.class), and BeanManager.unregister(XYZBean.class) on popular demand. why lose the opportunity ( before the next CDI spec) to make this a standard feature (that may be made optional for CDI containers to implement or ignore)? as a side note : even the API for starting & stopping CDI container is non-standard and left to implementations. was (Author: saasira): "CDI was designed to create the bean graph once at boot time giving us performance and limiting runtime exception on DI to the maximum." -- i agree that was primary purpose of CDI, and that is achieved with excellence. now, having reached a stable state of the stated goal, can't we scale to the next step? protective defaults are good for most of the cases, but it is those few cases which require adaptive flexibility to build "extra-mile" features. EJB provides UserTransaction besides Container Managed Transactions -- to let the developers handle specialized situations that cannot used CMT (of course, EJBContainer is also monolithic). for a start, you can leave the responsibility of validating bean-injection-point-interceptor-decorator-qualifier graph to the application developer; after all, it is his/her code is triggering registration/unregistration of beans at runtime, so he/she should be having all the details while processing bean registration events. let the application developer face the consequences of using this API wrongly with well defined exceptions. or if it is possible to validate the bean graph in CDI container itself (if no time or resource constraints), that would be a great thing to happen to Java EE -- a modular web application platform that was missing for several years. at least we should learn from the success of PHP CMS like Drupal which were modular for more than a decade now. Apache Deltaspike (a CDI implementation) provides some convenient API, though not to the extent of individual beans. ContextControl contextControl = BeanProvider.getContextualReference(ContextControl.class); // stoping the request context will dispose all the @RequestScoped beans contextControl.stopContext(RequestScoped.class); // and now restarting the request context, request scoped beans get reloaded by CDI container contextControl.startContext(RequestScoped.class); possibly some time in future they may also implement BeanManager.register(XYZBean.class), and BeanManager.unregister(XYZBean.class) on popular demand. why lose the opportunity ( before the next CDI spec) to make this a standard feature (that may be made optional for CDI containers to implement or ignore)? as a side note : even the API for starting & stopping CDI container is non-standard and left to implementations. > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 11:55:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Wed, 1 Feb 2017 11:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356875#comment-13356875 ] Laird Nelson commented on CDI-682: ---------------------------------- If you really need dynamic registration and are relying on CDI primarily for dependency injection and not much else, your philosophy of how things should work is better suited to something like [HK2|https://hk2.java.net/2.5.0-b32/]. I find that each toolkit has its uses. IMHO one of CDI's strengths is its static nature. > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 12:00:00 2017 From: issues at jboss.org (Samba Kolusu (JIRA)) Date: Wed, 1 Feb 2017 12:00:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356885#comment-13356885 ] Samba Kolusu commented on CDI-682: ---------------------------------- another argument in support of registering & unregistering beans, interceptors, decorators, producers etc at runtime could be "micro-services" - each module (with cdi beans & interceptors, injection-points, etc) being deployed & undeployed (or installed & uninstalled) at run time - each module providing a subset of the functionality that a monolithic web application provides in entirety. isn't microservices the hot topic that is being targeted for javaee 8? > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 1 12:21:00 2017 From: issues at jboss.org (Samba Kolusu (JIRA)) Date: Wed, 1 Feb 2017 12:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356903#comment-13356903 ] Samba Kolusu commented on CDI-682: ---------------------------------- [~ljnelson], but that means we will not be able to use CDI transactions, el, etc. not only that, even the module providers who write "micro services" as modules cannot use CDI either. so, essentially we are to use a DI framework meant for JAVA SE in a JAVA EE environment, and write all the EE features AGAIN? > Allow unregistration of CDI beans at run time, through API > ---------------------------------------------------------- > > Key: CDI-682 > URL: https://issues.jboss.org/browse/CDI-682 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Events, Interceptors > Affects Versions: 1.2.Final > Reporter: Samba Kolusu > > much like the ability to register beans at runtime through API (https://issues.jboss.org/browse/CDI-114) > also provide API > BeanManager::unregister("beanName"), or BeanManager::unregister(XYZBean.class) > to unregister beans at runtime, and corresponding events (BeforeUnregisteringBean, AfterUnregisteringBean, etc) so that interested listeners can take appropriate actions in the event of a bean getting removed from CDI context. > these two together will help build pluggable web applications much like OSGI modules. right now, installing new beans or removing exiting beans requires restart of CDI container, if not web application. with the addition of these two features [registering beans at run time, through BeanManager::register(XYZBean.class) ], and unregistering beans at runtime [BeanManager::unregister(XYZBean.class) ] true modularity comes to Java EE world, without the necessity to restart -- This message was sent by Atlassian JIRA (v7.2.3#72005) From antoine at sabot-durand.net Wed Feb 1 15:51:59 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 01 Feb 2017 20:51:59 +0000 Subject: [cdi-dev] CDI 2.0 is in public review Message-ID: In case you missed it: http://www.slideshare.net/antoinesd/cdi-20-is-upon-us-devoxx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170201/23ff7e5d/attachment.html From john.ament at spartasystems.com Wed Feb 1 16:02:34 2017 From: john.ament at spartasystems.com (John Ament) Date: Wed, 1 Feb 2017 21:02:34 +0000 Subject: [cdi-dev] CDI 2.0 is in public review In-Reply-To: References: Message-ID: Very nice. I got a request from them to do an extra talk about CDI 2 for Devoxx US (in addition to my currently scheduled talk). John D. Ament Cloud Software Architect Sparta Systems p. 609.807.5466 | m. 609.553.6130 john.ament at spartasystems.com | www.spartasystems.com ________________________________ From: cdi-dev-bounces at lists.jboss.org on behalf of Antoine Sabot-Durand Sent: Wednesday, February 1, 2017 3:51 PM To: CDI Java EE Specification Subject: [cdi-dev] CDI 2.0 is in public review In case you missed it: http://www.slideshare.net/antoinesd/cdi-20-is-upon-us-devoxx ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170201/190da04d/attachment-0001.html From antoine at sabot-durand.net Thu Feb 2 05:06:04 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 02 Feb 2017 10:06:04 +0000 Subject: [cdi-dev] CDI 2.0 release schedule Message-ID: Hi all, It seems I've been a little too optimistic with the release schedule for CDI 2.0. If we follow the JCP processes including publication delay and ballot we end with an aofficial final release around April 20th The planning looks something like: Feb 1st: Beginning of Public Review (https://jcp.org/en/resources/guide-pr) March 20th: end of Public Review ballot March 21st: submission of PFD (https://jcp.org/en/resources/guide-pfd) March 30th: Publication of PFD April 1st or preferably 2nd: Sending Final Elements ( https://jcp.org/en/resources/guide-final) April 8th: Start of Final Approval ballot April 22nd: End of FAB Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170202/f1c4cd35/attachment.html From antoine at sabot-durand.net Fri Feb 3 10:14:56 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 03 Feb 2017 15:14:56 +0000 Subject: [cdi-dev] CDI 2.0 is in public review In-Reply-To: References: Message-ID: Great news John, If you need element from my former CDI 2.0 talks, I can send you the slides... Antoine On Wed, Feb 1, 2017 at 10:02 PM John Ament wrote: > Very nice. I got a request from them to do an extra talk about CDI 2 for > Devoxx US (in addition to my currently scheduled talk). > > > John D. Ament > Cloud Software Architect > > Sparta Systems > > p. 609.807.5466 <(609)%20807-5466> | m. 609.553.6130 <(609)%20553-6130> > > john.ament at spartasystems.com | www.spartasystems.com > > > > > > ------------------------------ > *From:* cdi-dev-bounces at lists.jboss.org > on behalf of Antoine Sabot-Durand > *Sent:* Wednesday, February 1, 2017 3:51 PM > *To:* CDI Java EE Specification > *Subject:* [cdi-dev] CDI 2.0 is in public review > > In case you missed it: > > http://www.slideshare.net/antoinesd/cdi-20-is-upon-us-devoxx > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170203/ddf99d49/attachment.html From EMIJIANG at uk.ibm.com Tue Feb 7 11:11:31 2017 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 7 Feb 2017 16:11:31 +0000 Subject: [cdi-dev] Meeting today? In-Reply-To: References: Message-ID: Meeting today? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170207/f397ebb9/attachment.html From antoine at sabot-durand.net Tue Feb 7 11:16:01 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 07 Feb 2017 16:16:01 +0000 Subject: [cdi-dev] Meeting today? In-Reply-To: References: Message-ID: Hi Emily, M on PTO this week, so ne meeting. But next week there will be. Antoine Le mar. 7 f?vr. 2017 ? 17:12, Emily Jiang a ?crit : > Meeting today? > > Many thanks, > Emily > =========================== > Emily Jiang > WebSphere Application Server, CDI Development Lead > > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN > Phone: +44 (0)1962 816278 Internal: 246278 > > Email: emijiang at uk.ibm.com > Lotus Notes: Emily Jiang/UK/IBM at IBMGB > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170207/99e996a3/attachment.html From EMIJIANG at uk.ibm.com Tue Feb 7 12:32:50 2017 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Tue, 7 Feb 2017 17:32:50 +0000 Subject: [cdi-dev] Meeting today? In-Reply-To: References: Message-ID: Thanks Antoine! Talk to you next week. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB From: Antoine Sabot-Durand To: Emily Jiang/UK/IBM at IBMGB Cc: CDI Java EE Specification Date: 07/02/2017 16:17 Subject: Re: [cdi-dev] Meeting today? Sent by: cdi-dev-bounces at lists.jboss.org Hi Emily, M on PTO this week, so ne meeting. But next week there will be. Antoine Le mar. 7 f?vr. 2017 ? 17:12, Emily Jiang a ?crit : Meeting today? Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170207/88b1e3bd/attachment-0001.html From issues at jboss.org Thu Feb 9 14:03:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Thu, 9 Feb 2017 14:03:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-683) BeanConfigurator#produceWith(Function) does not allow access to InjectionPoint In-Reply-To: References: Message-ID: Laird Nelson created CDI-683: -------------------------------- Summary: BeanConfigurator#produceWith(Function) does not allow access to InjectionPoint Key: CDI-683 URL: https://issues.jboss.org/browse/CDI-683 Project: CDI Specification Issues Issue Type: Bug Components: Beans Affects Versions: 2.0 .Final Reporter: Laird Nelson The {{BeanConfigurator#produceWith(Function)}} method is intended to simulate a producer method, and is quite convenient. The {{Function}} that it takes accepts one parameter which is of type {{Instance}}. This is supposed to allow "faking" parameter injection in a producer method. One of the parameters that you commonly want in a producer method is the {{InjectionPoint}} for which the return value of the producer method is destined. If you try to "get" this {{InjectionPoint}} like this: {code} final Instance injectionPointInstance = instance.select(InjectionPoint.class); final InjectionPoint injectionPoint = injectionPointInstance.get(); {code} ...the {{InjectionPoint}} returned is _not_ the one you want, but instead a strange {{InjectionPoint}} that seems to represent something in the {{Instance}} class itself. The [{{InjectionPoint}} javadocs|http://docs.jboss.org/cdi/api/2.0.Beta1/javax/enterprise/inject/spi/InjectionPoint.html] say this about the matter: bq. If the injection point is a dynamically selected reference obtained [sic] then the metadata obtain [sic] reflects the injection point of the Instance, with the required type and any additional required qualifers [sic] defined by Instance.select(). I observe that Weld's behavior in this case matches the javadocs (if I'm understanding them right), but surely I should be able to get the {{InjectionPoint}} that is being serviced by my simulated producer method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 14 08:00:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 14 Feb 2017 08:00:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-684) Does portable extension should support static observer method In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-684: ---------------------------------------- Summary: Does portable extension should support static observer method Key: CDI-684 URL: https://issues.jboss.org/browse/CDI-684 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Reporter: Antoine Sabot-Durand Error reported in WELD-2331 brings the question of clarification of this point. Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 14 08:00:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 14 Feb 2017 08:00:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-684) Should portable extension support static observer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-684: ------------------------------------- Summary: Should portable extension support static observer method (was: Does portable extension should support static observer method) > Should portable extension support static observer method > -------------------------------------------------------- > > Key: CDI-684 > URL: https://issues.jboss.org/browse/CDI-684 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: Antoine Sabot-Durand > > Error reported in WELD-2331 brings the question of clarification of this point. > Should we forbid usage of static observer in extension class or not ? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 16 16:44:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Thu, 16 Feb 2017 16:44:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification In-Reply-To: References: Message-ID: Laird Nelson created CDI-685: -------------------------------- Summary: Section 1.2 does not describe relationship to javax.annotations specification Key: CDI-685 URL: https://issues.jboss.org/browse/CDI-685 Project: CDI Specification Issues Issue Type: Bug Components: Java EE integration, Java SE Integration Affects Versions: 2.0 .Final Reporter: Laird Nelson [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to_other_specifications] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Thu Feb 16 17:11:41 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Thu, 16 Feb 2017 22:11:41 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question Message-ID: This section ( http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events) says: "If other beans [other than the BeanManager] are injected into an [portable] extension?s observer methods, non-portable behavior results." Rephrased: a portable extension's observer methods must have a minimum of one parameter (the event being observed) and a maximum of two parameters (that plus the BeanManager), and none other if you want to stay truly portable. For true container lifecycle events, I understand this (you don't have beans to inject yet). But given that a bean must be provided by the container for a portable extension ( http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events), wouldn't it be reasonable to permit extra injection points in a portable extension's *non*-container-lifecycle-event-observing observer methods? Concretely, I'd like to do this: // In my portable extension private static final void doSomethingAtStartup(@Observes @Initialized(ApplicationScoped.class) final Object event, final Frobnicator someBean) { someBean.doSomething(); } ...but that would seem to be in violation of the specification. Could someone kindly explain why? Thanks, Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170216/fe966fee/attachment.html From manovotn at redhat.com Fri Feb 17 01:08:24 2017 From: manovotn at redhat.com (Matej Novotny) Date: Fri, 17 Feb 2017 01:08:24 -0500 (EST) Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: References: Message-ID: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> Hi, comment inline. ----- Original Message ----- > From: "Laird Nelson" > To: cdi-dev at lists.jboss.org > Sent: Thursday, February 16, 2017 11:11:41 PM > Subject: [cdi-dev] Extensions and spec-related observer method injection points question > > This section ( > http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: "If > other beans [other than the BeanManager ] are injected into an [portable] > extension?s observer methods, non-portable behavior results." > > Rephrased: a portable extension's observer methods must have a minimum of one > parameter (the event being observed) and a maximum of two parameters (that > plus the BeanManager ), and none other if you want to stay truly portable. That's correct interpretation. > For true container lifecycle events, I understand this (you don't have beans > to inject yet). But given that a bean must be provided by the container for > a portable extension ( > http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), wouldn't > it be reasonable to permit extra injection points in a portable extension's > non -container-lifecycle-event-observing observer methods? > > Concretely, I'd like to do this: > > // In my portable extension > private static final void doSomethingAtStartup(@Observes > @Initialized(ApplicationScoped.class) final Object event, final Frobnicator > someBean) { > someBean.doSomething(); > } While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean. > > ...but that would seem to be in violation of the specification. Could someone > kindly explain why? Not really sure, perhaps Martin or Antoine can share the details. But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't. Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there? SessionScoped for sure, how about Req? Conversation? > > Thanks, > Best, > Laird > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From issues at jboss.org Fri Feb 17 02:34:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 17 Feb 2017 02:34:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-685: ----------------------------- Issue Type: Clarification (was: Bug) > Section 1.2 does not describe relationship to javax.annotations specification > ----------------------------------------------------------------------------- > > Key: CDI-685 > URL: https://issues.jboss.org/browse/CDI-685 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration, Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Laird Nelson > > [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to_other_specifications] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 17 02:34:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 17 Feb 2017 02:34:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365158#comment-13365158 ] Martin Kouba commented on CDI-685: ---------------------------------- In fact, the spec does not even mention the fully qualified name of the priority annotation - {{javax.annotation.Priority}}! +1 for clarification > Section 1.2 does not describe relationship to javax.annotations specification > ----------------------------------------------------------------------------- > > Key: CDI-685 > URL: https://issues.jboss.org/browse/CDI-685 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration, Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Laird Nelson > > [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to_other_specifications] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Feb 17 02:56:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 17 Feb 2017 02:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-685) Section 1.2 does not describe relationship to javax.annotations specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365166#comment-13365166 ] Antoine Sabot-Durand commented on CDI-685: ------------------------------------------ Agree. For the record the 1st chapter of the spec is an introduction and not part of the spec as stated in [Doc Organisation section|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#doc_organisation], so error in it is not a spec issue strictly speaking but OTH we are more free to change this introcution to make it clearer and easier to get. > Section 1.2 does not describe relationship to javax.annotations specification > ----------------------------------------------------------------------------- > > Key: CDI-685 > URL: https://issues.jboss.org/browse/CDI-685 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration, Java SE Integration > Affects Versions: 2.0 .Final > Reporter: Laird Nelson > > [Section 1.2|http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#_relationship_to_other_specifications] of the specification does not describe a relationship to the {{javax.annotation}} specification. IMHO this is relevant because the usage of [{{@Priority}}|http://docs.oracle.com/javaee/7/api/javax/annotation/Priority.html] as an ordering mechanism for observer methods relies on its being applicable to method parameters, which in version 1.2 of the {{javax.annotation}} specification it is not. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From mkouba at redhat.com Fri Feb 17 03:16:28 2017 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 17 Feb 2017 09:16:28 +0100 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> Message-ID: Dne 17.2.2017 v 07:08 Matej Novotny napsal(a): > Hi, comment inline. > > ----- Original Message ----- >> From: "Laird Nelson" >> To: cdi-dev at lists.jboss.org >> Sent: Thursday, February 16, 2017 11:11:41 PM >> Subject: [cdi-dev] Extensions and spec-related observer method injection points question >> >> This section ( >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: "If >> other beans [other than the BeanManager ] are injected into an [portable] >> extension?s observer methods, non-portable behavior results." >> >> Rephrased: a portable extension's observer methods must have a minimum of one >> parameter (the event being observed) and a maximum of two parameters (that >> plus the BeanManager ), and none other if you want to stay truly portable. > > That's correct interpretation. > >> For true container lifecycle events, I understand this (you don't have beans >> to inject yet). But given that a bean must be provided by the container for >> a portable extension ( >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), wouldn't >> it be reasonable to permit extra injection points in a portable extension's >> non -container-lifecycle-event-observing observer methods? >> >> Concretely, I'd like to do this: >> >> // In my portable extension >> private static final void doSomethingAtStartup(@Observes >> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator >> someBean) { >> someBean.doSomething(); >> } > > While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean. > >> >> ...but that would seem to be in violation of the specification. Could someone It's not a violation, it's a non-portable behavior. Weld should not complain about the injection points of the doSomethingAtStartup() observer method. >> kindly explain why? > > Not really sure, perhaps Martin or Antoine can share the details. > But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't. Yes, I think the possible confusion was the only reason. > Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there? > SessionScoped for sure, how about Req? Conversation? > >> >> Thanks, >> Best, >> Laird >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code >> under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided on this list, the provider waives all patent and other intellectual >> property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Fri Feb 17 04:19:46 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 17 Feb 2017 09:19:46 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> Message-ID: Hi all, First Laird, thanks you for all your feedback on CDI, they are very helpful. This section is indeed not clear, but my understanding is this one: 1) As we mention the fact that BeanManager.fire() can be invoked in an extension lifecycle event observer, it makes sense to say observer on lifecycle payload are supported in extension, otherwise firing an event during the BeforeBeanDiscovery lifecycle event for instance would be useless since the only CDI elements "discovered" at this step are portable extensions I tested in various Weld and OWB version, observers on non lifecycle payload are called when BeanManager.fire() is called 2) If extension can contain observers with custom payload that can be invoked during container bootstrapping, it is quite understandable that adding parameters to these observer can bring issue: matching bean may not have been discovered yet and will result in an error. So for me, it makes sense to say that having an observer injecting something else than BeanManager in an extension is not safe and shouldn't be supported In other words void MyObserver(@Observes MyPayload payload) { ... ) and void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... ) are supported in an extension, but void MyObserver(@Observes MyPayload payload, MyBean bean) { ... ) is not because MyBean may be not discovered yet when observer will be triggered. Weld doesn't support it, while OWB does, so we face a non portable feature here ;). 3) A side effect of your mail made me also realise that we mention BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we should mention BeanManager.getEvent().select().fire()) This section really needs clarification, I'll create the ticket when we agree on what is part of the spec and not ;). Antoine On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba wrote: > Dne 17.2.2017 v 07:08 Matej Novotny napsal(a): > > Hi, comment inline. > > > > ----- Original Message ----- > >> From: "Laird Nelson" > >> To: cdi-dev at lists.jboss.org > >> Sent: Thursday, February 16, 2017 11:11:41 PM > >> Subject: [cdi-dev] Extensions and spec-related observer method > injection points question > >> > >> This section ( > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) > says: "If > >> other beans [other than the BeanManager ] are injected into an > [portable] > >> extension?s observer methods, non-portable behavior results." > >> > >> Rephrased: a portable extension's observer methods must have a minimum > of one > >> parameter (the event being observed) and a maximum of two parameters > (that > >> plus the BeanManager ), and none other if you want to stay truly > portable. > > > > That's correct interpretation. > > > >> For true container lifecycle events, I understand this (you don't have > beans > >> to inject yet). But given that a bean must be provided by the container > for > >> a portable extension ( > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), > wouldn't > >> it be reasonable to permit extra injection points in a portable > extension's > >> non -container-lifecycle-event-observing observer methods? > >> > >> Concretely, I'd like to do this: > >> > >> // In my portable extension > >> private static final void doSomethingAtStartup(@Observes > >> @Initialized(ApplicationScoped.class) final Object event, final > Frobnicator > >> someBean) { > >> someBean.doSomething(); > >> } > > > > While you cannot do this, you can still get hold of BeanManager and use > it to resolve your bean. > > > >> > >> ...but that would seem to be in violation of the specification. Could > someone > > It's not a violation, it's a non-portable behavior. Weld should not > complain about the injection points of the doSomethingAtStartup() > observer method. > > >> kindly explain why? > > > > Not really sure, perhaps Martin or Antoine can share the details. > > But I would say this could create quite some confusion if in some > observer you could inject certain beans and in others you couldn't. > > Yes, I think the possible confusion was the only reason. > > > Even in your sample, you can only inject AppScoped beans, so imagine you > do such observer for, say, SessionScoped, what can you inject there? > > SessionScoped for sure, how about Req? Conversation? > > > >> > >> Thanks, > >> Best, > >> Laird > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > code > >> under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other > intellectual > >> property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/4dd1d035/attachment.html From mkouba at redhat.com Fri Feb 17 04:36:21 2017 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 17 Feb 2017 10:36:21 +0100 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> Message-ID: <935a49d9-71e7-54dd-be0d-ecf9c49f8086@redhat.com> Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a): > Hi all, > > First Laird, thanks you for all your feedback on CDI, they are very helpful. > This section is indeed not clear, but my understanding is this one: > > 1) As we mention the fact that BeanManager.fire() can be invoked in an > extension lifecycle event observer, it makes sense to say observer on > lifecycle payload are supported in extension, otherwise firing an event > during the BeforeBeanDiscovery lifecycle event for instance would be > useless since the only CDI elements "discovered" at this step are > portable extensions > > I tested in various Weld and OWB version, observers on non lifecycle > payload are called when BeanManager.fire() is called > > 2) If extension can contain observers with custom payload that can be > invoked during container bootstrapping, it is quite understandable that > adding parameters to these observer can bring issue: matching bean may > not have been discovered yet and will result in an error. That's a good point. > So for me, it makes sense to say that having an observer injecting something else than > BeanManager in an extension is not safe and shouldn't be supported > In other words > > void MyObserver(@Observes MyPayload payload) { ... ) > > and > > void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... ) > > are supported in an extension, but > > void MyObserver(@Observes MyPayload payload, MyBean bean) { ... ) > > is not because MyBean may be not discovered yet when observer will be > triggered. > > Weld doesn't support it Are you sure Antoine? I quicly checked the Weld 3 codebase and "myObserver(@Observes MyPayload payload, MyBean bean)" should work. We only check injection points for container lifecycle events... >, while OWB does, so we face a non portable > feature here ;). > > 3) A side effect of your mail made me also realise that we mention > BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we > should mention BeanManager.getEvent().select().fire()) > > This section really needs clarification, I'll create the ticket when we > agree on what is part of the spec and not ;). > > > Antoine > > > On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba > wrote: > > Dne 17.2.2017 v 07:08 Matej Novotny napsal(a): > > Hi, comment inline. > > > > ----- Original Message ----- > >> From: "Laird Nelson" > > >> To: cdi-dev at lists.jboss.org > >> Sent: Thursday, February 16, 2017 11:11:41 PM > >> Subject: [cdi-dev] Extensions and spec-related observer method > injection points question > >> > >> This section ( > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events > ) says: "If > >> other beans [other than the BeanManager ] are injected into an > [portable] > >> extension?s observer methods, non-portable behavior results." > >> > >> Rephrased: a portable extension's observer methods must have a > minimum of one > >> parameter (the event being observed) and a maximum of two > parameters (that > >> plus the BeanManager ), and none other if you want to stay truly > portable. > > > > That's correct interpretation. > > > >> For true container lifecycle events, I understand this (you don't > have beans > >> to inject yet). But given that a bean must be provided by the > container for > >> a portable extension ( > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events > ), wouldn't > >> it be reasonable to permit extra injection points in a portable > extension's > >> non -container-lifecycle-event-observing observer methods? > >> > >> Concretely, I'd like to do this: > >> > >> // In my portable extension > >> private static final void doSomethingAtStartup(@Observes > >> @Initialized(ApplicationScoped.class) final Object event, final > Frobnicator > >> someBean) { > >> someBean.doSomething(); > >> } > > > > While you cannot do this, you can still get hold of BeanManager > and use it to resolve your bean. > > > >> > >> ...but that would seem to be in violation of the specification. > Could someone > > It's not a violation, it's a non-portable behavior. Weld should not > complain about the injection points of the doSomethingAtStartup() > observer method. > > >> kindly explain why? > > > > Not really sure, perhaps Martin or Antoine can share the details. > > But I would say this could create quite some confusion if in some > observer you could inject certain beans and in others you couldn't. > > Yes, I think the possible confusion was the only reason. > > > Even in your sample, you can only inject AppScoped beans, so > imagine you do such observer for, say, SessionScoped, what can you > inject there? > > SessionScoped for sure, how about Req? Conversation? > > > >> > >> Thanks, > >> Best, > >> Laird > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider > licenses the code > >> under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas > >> provided on this list, the provider waives all patent and other > intellectual > >> property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider > licenses the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses > the code under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > ideas provided on this list, the provider waives all patent and > other intellectual property rights inherent in such information. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From antoine at sabot-durand.net Fri Feb 17 04:52:59 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 17 Feb 2017 09:52:59 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: <935a49d9-71e7-54dd-be0d-ecf9c49f8086@redhat.com> References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> <935a49d9-71e7-54dd-be0d-ecf9c49f8086@redhat.com> Message-ID: On Fri, Feb 17, 2017 at 10:36 AM Martin Kouba wrote: > Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a): > > Hi all, > > > > First Laird, thanks you for all your feedback on CDI, they are very > helpful. > > This section is indeed not clear, but my understanding is this one: > > > > 1) As we mention the fact that BeanManager.fire() can be invoked in an > > extension lifecycle event observer, it makes sense to say observer on > > lifecycle payload are supported in extension, otherwise firing an event > > during the BeforeBeanDiscovery lifecycle event for instance would be > > useless since the only CDI elements "discovered" at this step are > > portable extensions > > > > I tested in various Weld and OWB version, observers on non lifecycle > > payload are called when BeanManager.fire() is called > > > > 2) If extension can contain observers with custom payload that can be > > invoked during container bootstrapping, it is quite understandable that > > adding parameters to these observer can bring issue: matching bean may > > not have been discovered yet and will result in an error. > > That's a good point. > > > So for me, it makes sense to say that having an observer injecting > something else than > > BeanManager in an extension is not safe and shouldn't be supported > > In other words > > > > void MyObserver(@Observes MyPayload payload) { ... ) > > > > and > > > > void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... ) > > > > are supported in an extension, but > > > > void MyObserver(@Observes MyPayload payload, MyBean bean) { ... ) > > > > is not because MyBean may be not discovered yet when observer will be > > triggered. > > > > Weld doesn't support it > > Are you sure Antoine? I quicly checked the Weld 3 codebase and > "myObserver(@Observes MyPayload payload, MyBean bean)" should work. We > only check injection points for container lifecycle events... > Oops, you're right, I was a bit too fast in my writing, what is not supported in Weld (tested with 2.3.2, 2.4.2 and 3.0.0-CR1)and works in OWB is void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object payload, MyBean bean) { ... ) Weld throws the following exception: WELD-000409: Observer method for container lifecycle event can only inject BeanManager Which is not very clear since the payload is not exactly a container lifecycle event... > >, while OWB does, so we face a non portable > > feature here ;). > > > > 3) A side effect of your mail made me also realise that we mention > > BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we > > should mention BeanManager.getEvent().select().fire()) > > > > This section really needs clarification, I'll create the ticket when we > > agree on what is part of the spec and not ;). > > > > > > Antoine > > > > > > On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba > > wrote: > > > > Dne 17.2.2017 v 07:08 Matej Novotny napsal(a): > > > Hi, comment inline. > > > > > > ----- Original Message ----- > > >> From: "Laird Nelson" ljnelson at gmail.com>> > > >> To: cdi-dev at lists.jboss.org > > >> Sent: Thursday, February 16, 2017 11:11:41 PM > > >> Subject: [cdi-dev] Extensions and spec-related observer method > > injection points question > > >> > > >> This section ( > > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events > > ) says: "If > > >> other beans [other than the BeanManager ] are injected into an > > [portable] > > >> extension?s observer methods, non-portable behavior results." > > >> > > >> Rephrased: a portable extension's observer methods must have a > > minimum of one > > >> parameter (the event being observed) and a maximum of two > > parameters (that > > >> plus the BeanManager ), and none other if you want to stay truly > > portable. > > > > > > That's correct interpretation. > > > > > >> For true container lifecycle events, I understand this (you don't > > have beans > > >> to inject yet). But given that a bean must be provided by the > > container for > > >> a portable extension ( > > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events > > ), wouldn't > > >> it be reasonable to permit extra injection points in a portable > > extension's > > >> non -container-lifecycle-event-observing observer methods? > > >> > > >> Concretely, I'd like to do this: > > >> > > >> // In my portable extension > > >> private static final void doSomethingAtStartup(@Observes > > >> @Initialized(ApplicationScoped.class) final Object event, final > > Frobnicator > > >> someBean) { > > >> someBean.doSomething(); > > >> } > > > > > > While you cannot do this, you can still get hold of BeanManager > > and use it to resolve your bean. > > > > > >> > > >> ...but that would seem to be in violation of the specification. > > Could someone > > > > It's not a violation, it's a non-portable behavior. Weld should not > > complain about the injection points of the doSomethingAtStartup() > > observer method. > > > > >> kindly explain why? > > > > > > Not really sure, perhaps Martin or Antoine can share the details. > > > But I would say this could create quite some confusion if in some > > observer you could inject certain beans and in others you couldn't. > > > > Yes, I think the possible confusion was the only reason. > > > > > Even in your sample, you can only inject AppScoped beans, so > > imagine you do such observer for, say, SessionScoped, what can you > > inject there? > > > SessionScoped for sure, how about Req? Conversation? > > > > > >> > > >> Thanks, > > >> Best, > > >> Laird > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> > > >> Note that for all code provided on this list, the provider > > licenses the code > > >> under the Apache License, Version 2 > > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas > > >> provided on this list, the provider waives all patent and other > > intellectual > > >> property rights inherent in such information. > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > > > -- > > Martin Kouba > > Senior Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/0a43985d/attachment.html From antoine at sabot-durand.net Fri Feb 17 06:37:05 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 17 Feb 2017 11:37:05 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> <935a49d9-71e7-54dd-be0d-ecf9c49f8086@redhat.com> Message-ID: After discussing and testing with Martin we discovered that having an Observer with a payload of type Object and an injected parameter that is not BeanManager is not supported. For instance: void MyObserver(@Observes Object payload, MyBean bean) { ... ) Which makes sense since with observer resolution rules this observer will be invoked for all Lifecycle events. Now, when the payload has a qualifier this makes no difference for Weld and the deployment also fails with: void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object payload, MyBean bean) { ... ) So discussion may focus on supporting this very specific use case in Weld and eventually in the spec. Antoine On Fri, Feb 17, 2017 at 10:52 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > On Fri, Feb 17, 2017 at 10:36 AM Martin Kouba wrote: > > Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a): > > Hi all, > > > > First Laird, thanks you for all your feedback on CDI, they are very > helpful. > > This section is indeed not clear, but my understanding is this one: > > > > 1) As we mention the fact that BeanManager.fire() can be invoked in an > > extension lifecycle event observer, it makes sense to say observer on > > lifecycle payload are supported in extension, otherwise firing an event > > during the BeforeBeanDiscovery lifecycle event for instance would be > > useless since the only CDI elements "discovered" at this step are > > portable extensions > > > > I tested in various Weld and OWB version, observers on non lifecycle > > payload are called when BeanManager.fire() is called > > > > 2) If extension can contain observers with custom payload that can be > > invoked during container bootstrapping, it is quite understandable that > > adding parameters to these observer can bring issue: matching bean may > > not have been discovered yet and will result in an error. > > That's a good point. > > > So for me, it makes sense to say that having an observer injecting > something else than > > BeanManager in an extension is not safe and shouldn't be supported > > In other words > > > > void MyObserver(@Observes MyPayload payload) { ... ) > > > > and > > > > void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... ) > > > > are supported in an extension, but > > > > void MyObserver(@Observes MyPayload payload, MyBean bean) { ... ) > > > > is not because MyBean may be not discovered yet when observer will be > > triggered. > > > > Weld doesn't support it > > Are you sure Antoine? I quicly checked the Weld 3 codebase and > "myObserver(@Observes MyPayload payload, MyBean bean)" should work. We > only check injection points for container lifecycle events... > > > Oops, you're right, I was a bit too fast in my writing, what is not > supported in Weld (tested with 2.3.2, 2.4.2 and 3.0.0-CR1)and works in OWB > is > > void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object > payload, MyBean bean) { ... ) > > Weld throws the following exception: > > WELD-000409: Observer method for container lifecycle event can only inject > BeanManager > > Which is not very clear since the payload is not exactly a container > lifecycle event... > > > > >, while OWB does, so we face a non portable > > > > feature here ;). > > > > 3) A side effect of your mail made me also realise that we mention > > BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we > > should mention BeanManager.getEvent().select().fire()) > > > > This section really needs clarification, I'll create the ticket when we > > agree on what is part of the spec and not ;). > > > > > > Antoine > > > > > > On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba > > wrote: > > > > Dne 17.2.2017 v 07:08 Matej Novotny napsal(a): > > > Hi, comment inline. > > > > > > ----- Original Message ----- > > >> From: "Laird Nelson" ljnelson at gmail.com>> > > >> To: cdi-dev at lists.jboss.org > > >> Sent: Thursday, February 16, 2017 11:11:41 PM > > >> Subject: [cdi-dev] Extensions and spec-related observer method > > injection points question > > >> > > >> This section ( > > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events > > ) says: "If > > >> other beans [other than the BeanManager ] are injected into an > > [portable] > > >> extension?s observer methods, non-portable behavior results." > > >> > > >> Rephrased: a portable extension's observer methods must have a > > minimum of one > > >> parameter (the event being observed) and a maximum of two > > parameters (that > > >> plus the BeanManager ), and none other if you want to stay truly > > portable. > > > > > > That's correct interpretation. > > > > > >> For true container lifecycle events, I understand this (you don't > > have beans > > >> to inject yet). But given that a bean must be provided by the > > container for > > >> a portable extension ( > > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events > > ), wouldn't > > >> it be reasonable to permit extra injection points in a portable > > extension's > > >> non -container-lifecycle-event-observing observer methods? > > >> > > >> Concretely, I'd like to do this: > > >> > > >> // In my portable extension > > >> private static final void doSomethingAtStartup(@Observes > > >> @Initialized(ApplicationScoped.class) final Object event, final > > Frobnicator > > >> someBean) { > > >> someBean.doSomething(); > > >> } > > > > > > While you cannot do this, you can still get hold of BeanManager > > and use it to resolve your bean. > > > > > >> > > >> ...but that would seem to be in violation of the specification. > > Could someone > > > > It's not a violation, it's a non-portable behavior. Weld should not > > complain about the injection points of the doSomethingAtStartup() > > observer method. > > > > >> kindly explain why? > > > > > > Not really sure, perhaps Martin or Antoine can share the details. > > > But I would say this could create quite some confusion if in some > > observer you could inject certain beans and in others you couldn't. > > > > Yes, I think the possible confusion was the only reason. > > > > > Even in your sample, you can only inject AppScoped beans, so > > imagine you do such observer for, say, SessionScoped, what can you > > inject there? > > > SessionScoped for sure, how about Req? Conversation? > > > > > >> > > >> Thanks, > > >> Best, > > >> Laird > > >> > > >> _______________________________________________ > > >> cdi-dev mailing list > > >> cdi-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >> > > >> Note that for all code provided on this list, the provider > > licenses the code > > >> under the Apache License, Version 2 > > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas > > >> provided on this list, the provider waives all patent and other > > intellectual > > >> property rights inherent in such information. > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > Note that for all code provided on this list, the provider > > licenses the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > > > > -- > > Martin Kouba > > Senior Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses > > the code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other > > ideas provided on this list, the provider waives all patent and > > other intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/dd2b2dfe/attachment-0001.html From ljnelson at gmail.com Fri Feb 17 11:47:44 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Fri, 17 Feb 2017 16:47:44 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> <935a49d9-71e7-54dd-be0d-ecf9c49f8086@redhat.com> Message-ID: On Fri, Feb 17, 2017 at 3:37 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > After discussing and testing with Martin we discovered that having an > Observer with a payload of type Object and an injected parameter that is > not BeanManager is not supported. > > For instance: > void MyObserver(@Observes Object payload, MyBean bean) { ... ) > > Which makes sense since with observer resolution rules this observer will > be invoked for all Lifecycle events. > Oh, that very specific aspect is an aspect I hadn't considered. That makes sense. Your earlier point about how MyBean might not be resolved at invocation time was one I didn't understand. If I have: void MyObserver(@Observes @Initialized(ApplicationScoped.class) Object payload, MyBean bean) { ... } ...then surely MyBean would be resolved at this point, by definition? (I understand you're looking at this specific case, but even more generally here: wouldn't MyBean be guaranteed to be resolved here?) Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/fec3c5ed/attachment.html From ljnelson at gmail.com Fri Feb 17 11:56:04 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Fri, 17 Feb 2017 16:56:04 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> Message-ID: On Thu, Feb 16, 2017 at 10:08 PM Matej Novotny wrote: > > Concretely, I'd like to do this: > > > > // In my portable extension > > private static final void doSomethingAtStartup(@Observes > > @Initialized(ApplicationScoped.class) final Object event, final > Frobnicator > > someBean) { > > someBean.doSomething(); > > } > > While you cannot do this, you can still get hold of BeanManager and use it > to resolve your bean. > Right; that's what I'm doing at the moment. > But I would say this could create quite some confusion if in some observer > you could inject certain beans and in others you couldn't. > Sure. > Even in your sample, you can only inject AppScoped beans, so imagine you > do such observer for, say, SessionScoped, what can you inject there? > SessionScoped for sure, how about Req? Conversation? > First, thanks to Martin, Antoine, yourself, etc. for looking at this. The issue is not holding me up, and I can make headway, etc. My remarks here are just because I'm curious. :-) Forgetting about confusion, couldn't I inject any bean I want in a non-container-lifecycle-event-observing observer method in my extension? I understand it's not supported right now, and I also understand Antoine's excellent point that observing a payload of type Object would, in a portable extension, be too "broad". Let's forget about that for a moment, and pretend that it's not an issue, and just focus on resolution issues. Surely this: void MyObserver(@Observes Object payload, SomeBean bean) { ... } ...would work (again, forgetting about the fact that due to resolution rules this would also be called for lifecycle events; I'm interested purely in resolution issues of that SomeBean parameter)? My point is, a portable extension "becomes" a bean (in application scope, according to the specification), and so therefore is eligible to use other beans, no matter what scope they're in, some of whose Contexts might be active, and some of whose might not be active. Obviously trying to use a bean before the container has gotten through AfterDeploymentValidation won't work, but after that point...? Like I said, now I'm just curious. :-) Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/35dab4fa/attachment.html From antoine at sabot-durand.net Fri Feb 17 12:30:05 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 17 Feb 2017 17:30:05 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> Message-ID: Check https://issues.jboss.org/browse/WELD-2338 Regarding Extension being beans, it's the case, but rather special beans since you can't perform field, constructor or initializer injection in them. For observer that might be called during bootstrap (observing Object for instance) they will throw exception if they inject parameters as well since their matching beans are not resolvable yet. A good practice could be: use observers with personal payload without parameter injection and only for specific operation during bootstrap (Romain wrote an interesting post on the topic: https://blog-rmannibucau.rhcloud.com/#/post/share-data-in-cdi-extensions) Create a specific bean to declare your observers and inject the extension and other beans as parameter. If you really want to have your observers in your extension, inject BeanManager and perform the resolution with it... Antoine On Fri, Feb 17, 2017 at 5:56 PM Laird Nelson wrote: > On Thu, Feb 16, 2017 at 10:08 PM Matej Novotny > wrote: > > > Concretely, I'd like to do this: > > > > // In my portable extension > > private static final void doSomethingAtStartup(@Observes > > @Initialized(ApplicationScoped.class) final Object event, final > Frobnicator > > someBean) { > > someBean.doSomething(); > > } > > While you cannot do this, you can still get hold of BeanManager and use it > to resolve your bean. > > > Right; that's what I'm doing at the moment. > > > But I would say this could create quite some confusion if in some observer > you could inject certain beans and in others you couldn't. > > > Sure. > > > Even in your sample, you can only inject AppScoped beans, so imagine you > do such observer for, say, SessionScoped, what can you inject there? > SessionScoped for sure, how about Req? Conversation? > > > First, thanks to Martin, Antoine, yourself, etc. for looking at this. The > issue is not holding me up, and I can make headway, etc. My remarks here > are just because I'm curious. :-) > > Forgetting about confusion, couldn't I inject any bean I want in a > non-container-lifecycle-event-observing observer method in my extension? I > understand it's not supported right now, and I also understand Antoine's > excellent point that observing a payload of type Object would, in a > portable extension, be too "broad". Let's forget about that for a moment, > and pretend that it's not an issue, and just focus on resolution issues. > > Surely this: > > void MyObserver(@Observes Object payload, SomeBean bean) { ... } > > ...would work (again, forgetting about the fact that due to resolution > rules this would also be called for lifecycle events; I'm interested purely > in resolution issues of that SomeBean parameter)? > > My point is, a portable extension "becomes" a bean (in application scope, > according to the specification), and so therefore is eligible to use other > beans, no matter what scope they're in, some of whose Contexts might be > active, and some of whose might not be active. Obviously trying to use a > bean before the container has gotten through AfterDeploymentValidation > won't work, but after that point...? > > Like I said, now I'm just curious. :-) > > Best, > Laird > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/044f7b1c/attachment-0001.html From ljnelson at gmail.com Fri Feb 17 12:37:26 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Fri, 17 Feb 2017 17:37:26 +0000 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> Message-ID: On Fri, Feb 17, 2017 at 9:30 AM Antoine Sabot-Durand < antoine at sabot-durand.net> wrote: > Regarding Extension being beans, it's the case, but rather special beans > since you can't perform field, constructor or initializer injection in them. > Sure; obviously there are issues with exactly when a portable extension "becomes" a bean. You don't want to use "bean-like" features while the container is still coming up. > For observer that might be called during bootstrap (observing Object for > instance) they will throw exception if they inject parameters as well since > their matching beans are not resolvable yet. > Right; this was an excellent point you made earlier?specifically the part about observing Object; the related point that other observer method parameters might not be resolved seemed irrelevant to me, since by definition a non-container-lifecycle-event-observing observer method would not be invoked until deployment validation was complete?and which I had not thought about. > A good practice could be: use observers with personal payload without > parameter injection and only for specific operation during bootstrap > (Romain wrote an interesting post on the topic: > https://blog-rmannibucau.rhcloud.com/#/post/share-data-in-cdi-extensions) > Create a specific bean to declare your observers and inject the extension > and other beans as parameter. > Yes; I am heading this way. I had some shared state across lifecycle event observers and "regular" observers and was hoping to keep that isolated to a private instance variable but I can refactor this. > If you really want to have your observers in your extension, inject > BeanManager and perform the resolution with it... > That's what I'm doing now but it doesn't "read" as nicely; that's fine. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170217/61d4bb23/attachment.html From issues at jboss.org Sun Feb 19 12:55:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Sun, 19 Feb 2017 12:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365798#comment-13365798 ] Vincent Massol commented on CDI-114: ------------------------------------ Hi guys. I was wondering if there was now a recommended way of supporting the main use case I listed above back in 2011, namely: If you have a CDI application, how can you add support for installing extensions at runtime for this application (for example by adding JARs containing beans to the classloader), and tell the Bean Manager to take into account those news beans? I suspect this is a common need for apps as they grow (i.e. the ability to dynamically add extensions). As I mentioned back then, we've been supporting this in XWiki for about 10 years now with our custom handmade solution but I hate using custom solutions when there exists standard solutions so I'm always on the lookout for such solutions. I've been wanting to try to use CDI for years now but have dropped it in 2011 because of the lack of a solution. The only option I've heard so far would be to tell the Bean Manager to "restart" and thus re-run the process of creating/resolving the Bean graph. Is that still the only solution? However, I'm worried that this would take too long for our needs since XWiki has thousands (possibly tens of thousands) of Beans running, coming from hundreds of JAR files. Is this "restart"/"reload" already implemented and optimized so that there's no rescanning of JAR files for example? Does anyone have any experience with this? Thanks a lot! > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Feb 19 14:59:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Sun, 19 Feb 2017 14:59:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365802#comment-13365802 ] Mark Struberg commented on CDI-114: ----------------------------------- What is your exact use case? Usually the bean graph and Classpath per application is pretty much static once booted. Except during development. If it's just for development then you might look at https://github.com/HotswapProjects > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From struberg at yahoo.de Sun Feb 19 15:06:32 2017 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 19 Feb 2017 21:06:32 +0100 Subject: [cdi-dev] Fwd: Extensions and spec-related observer method injection points question References: <6014FE91-679E-4EA9-918A-81B175652164@yahoo.de> Message-ID: Sorry, should go to reply-all. LieGrue, strub > Anfang der weitergeleiteten Nachricht: > > Von: Mark Struberg > Betreff: Aw: [cdi-dev] Extensions and spec-related observer method injection points question > Datum: 19. Februar 2017 um 21:05:30 MEZ > An: Matej Novotny > >> >> While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean. > > No, you cannot. At least not before AfterBeanValidation. > > LieGrue, > strub > > >> Am 17.02.2017 um 07:08 schrieb Matej Novotny : >> >> Hi, comment inline. >> >> ----- Original Message ----- >>> From: "Laird Nelson" >>> To: cdi-dev at lists.jboss.org >>> Sent: Thursday, February 16, 2017 11:11:41 PM >>> Subject: [cdi-dev] Extensions and spec-related observer method injection points question >>> >>> This section ( >>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: "If >>> other beans [other than the BeanManager ] are injected into an [portable] >>> extension?s observer methods, non-portable behavior results." >>> >>> Rephrased: a portable extension's observer methods must have a minimum of one >>> parameter (the event being observed) and a maximum of two parameters (that >>> plus the BeanManager ), and none other if you want to stay truly portable. >> >> That's correct interpretation. >> >>> For true container lifecycle events, I understand this (you don't have beans >>> to inject yet). But given that a bean must be provided by the container for >>> a portable extension ( >>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), wouldn't >>> it be reasonable to permit extra injection points in a portable extension's >>> non -container-lifecycle-event-observing observer methods? >>> >>> Concretely, I'd like to do this: >>> >>> // In my portable extension >>> private static final void doSomethingAtStartup(@Observes >>> @Initialized(ApplicationScoped.class) final Object event, final Frobnicator >>> someBean) { >>> someBean.doSomething(); >>> } >> >> While you cannot do this, you can still get hold of BeanManager and use it to resolve your bean. >> >>> >>> ...but that would seem to be in violation of the specification. Could someone >>> kindly explain why? >> >> Not really sure, perhaps Martin or Antoine can share the details. >> But I would say this could create quite some confusion if in some observer you could inject certain beans and in others you couldn't. >> Even in your sample, you can only inject AppScoped beans, so imagine you do such observer for, say, SessionScoped, what can you inject there? >> SessionScoped for sure, how about Req? Conversation? >> >>> >>> Thanks, >>> Best, >>> Laird >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code >>> under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>> provided on this list, the provider waives all patent and other intellectual >>> property rights inherent in such information. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170219/378d97e2/attachment.html From struberg at yahoo.de Sun Feb 19 15:07:35 2017 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 19 Feb 2017 21:07:35 +0100 Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: <935a49d9-71e7-54dd-be0d-ecf9c49f8086@redhat.com> References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> <935a49d9-71e7-54dd-be0d-ecf9c49f8086@redhat.com> Message-ID: <3F228771-D8DE-4DD5-9089-68D4CB01737A@yahoo.de> What you can portably do is to fire an event in one CDI Extension and observe it in another Extension. Note: not a normal bean, as they are not yet started, but Extension is fine. There is even a TCK test for it. LieGrue, strub > Am 17.02.2017 um 10:36 schrieb Martin Kouba : > > Dne 17.2.2017 v 10:19 Antoine Sabot-Durand napsal(a): >> Hi all, >> >> First Laird, thanks you for all your feedback on CDI, they are very helpful. >> This section is indeed not clear, but my understanding is this one: >> >> 1) As we mention the fact that BeanManager.fire() can be invoked in an >> extension lifecycle event observer, it makes sense to say observer on >> lifecycle payload are supported in extension, otherwise firing an event >> during the BeforeBeanDiscovery lifecycle event for instance would be >> useless since the only CDI elements "discovered" at this step are >> portable extensions >> >> I tested in various Weld and OWB version, observers on non lifecycle >> payload are called when BeanManager.fire() is called >> >> 2) If extension can contain observers with custom payload that can be >> invoked during container bootstrapping, it is quite understandable that >> adding parameters to these observer can bring issue: matching bean may >> not have been discovered yet and will result in an error. > > That's a good point. > >> So for me, it makes sense to say that having an observer injecting something else than >> BeanManager in an extension is not safe and shouldn't be supported >> In other words >> >> void MyObserver(@Observes MyPayload payload) { ... ) >> >> and >> >> void MyObserver(@Observes MyPayload payload, BeanManager bm) { ... ) >> >> are supported in an extension, but >> >> void MyObserver(@Observes MyPayload payload, MyBean bean) { ... ) >> >> is not because MyBean may be not discovered yet when observer will be >> triggered. >> >> Weld doesn't support it > > Are you sure Antoine? I quicly checked the Weld 3 codebase and > "myObserver(@Observes MyPayload payload, MyBean bean)" should work. We > only check injection points for container lifecycle events... > >> , while OWB does, so we face a non portable >> feature here ;). >> >> 3) A side effect of your mail made me also realise that we mention >> BeanManger.fire() in this section despite its deprecation in CDI 2.0 (we >> should mention BeanManager.getEvent().select().fire()) >> >> This section really needs clarification, I'll create the ticket when we >> agree on what is part of the spec and not ;). >> >> >> Antoine >> >> >> On Fri, Feb 17, 2017 at 9:16 AM Martin Kouba > > wrote: >> >> Dne 17.2.2017 v 07:08 Matej Novotny napsal(a): >>> Hi, comment inline. >>> >>> ----- Original Message ----- >>>> From: "Laird Nelson" > >>>> To: cdi-dev at lists.jboss.org >>>> Sent: Thursday, February 16, 2017 11:11:41 PM >>>> Subject: [cdi-dev] Extensions and spec-related observer method >> injection points question >>>> >>>> This section ( >>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events >> ) says: "If >>>> other beans [other than the BeanManager ] are injected into an >> [portable] >>>> extension?s observer methods, non-portable behavior results." >>>> >>>> Rephrased: a portable extension's observer methods must have a >> minimum of one >>>> parameter (the event being observed) and a maximum of two >> parameters (that >>>> plus the BeanManager ), and none other if you want to stay truly >> portable. >>> >>> That's correct interpretation. >>> >>>> For true container lifecycle events, I understand this (you don't >> have beans >>>> to inject yet). But given that a bean must be provided by the >> container for >>>> a portable extension ( >>>> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events >> ), wouldn't >>>> it be reasonable to permit extra injection points in a portable >> extension's >>>> non -container-lifecycle-event-observing observer methods? >>>> >>>> Concretely, I'd like to do this: >>>> >>>> // In my portable extension >>>> private static final void doSomethingAtStartup(@Observes >>>> @Initialized(ApplicationScoped.class) final Object event, final >> Frobnicator >>>> someBean) { >>>> someBean.doSomething(); >>>> } >>> >>> While you cannot do this, you can still get hold of BeanManager >> and use it to resolve your bean. >>> >>>> >>>> ...but that would seem to be in violation of the specification. >> Could someone >> >> It's not a violation, it's a non-portable behavior. Weld should not >> complain about the injection points of the doSomethingAtStartup() >> observer method. >> >>>> kindly explain why? >>> >>> Not really sure, perhaps Martin or Antoine can share the details. >>> But I would say this could create quite some confusion if in some >> observer you could inject certain beans and in others you couldn't. >> >> Yes, I think the possible confusion was the only reason. >> >>> Even in your sample, you can only inject AppScoped beans, so >> imagine you do such observer for, say, SessionScoped, what can you >> inject there? >>> SessionScoped for sure, how about Req? Conversation? >>> >>>> >>>> Thanks, >>>> Best, >>>> Laird >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider >> licenses the code >>>> under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas >>>> provided on this list, the provider waives all patent and other >> intellectual >>>> property rights inherent in such information. >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider >> licenses the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >>> >> >> -- >> Martin Kouba >> Senior Software Engineer >> Red Hat, Czech Republic >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses >> the code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other >> ideas provided on this list, the provider waives all patent and >> other intellectual property rights inherent in such information. >> > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From issues at jboss.org Sun Feb 19 16:43:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Sun, 19 Feb 2017 16:43:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365809#comment-13365809 ] Vincent Massol commented on CDI-114: ------------------------------------ Hi [~struberg]. My exact use case is the following: allowing users of XWiki the ability to install extensions at runtime and without restarting XWiki, and these extensions contain Beans (Components in XWiki terminology) that need to be instantiated/populated and injected in other beans/code requiring them. So this is indeed not for development time but at runtime, when using XWiki in production. Thanks > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Feb 19 18:01:00 2017 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sun, 19 Feb 2017 18:01:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365811#comment-13365811 ] arjan tijms commented on CDI-114: --------------------------------- This could also help with the longstanding limitation that web.xml content can not be used for registering beans, since at the time the CDI extension is executed the {{ServletContext}} (and with it, WEB-INF/*) is not yet available. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 01:31:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 20 Feb 2017 01:31:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365831#comment-13365831 ] Mark Struberg commented on CDI-114: ----------------------------------- [~atijms] That is totally up to the container. It's simply not defined, so you cannot be sure. [~vmassol] I see. So you allow that your users upload some jar which you then dynamically add to you Classpath? Or how does the XWiki container become aware of that new functionality? Does XWiki use OSGi (which would be suited for such a dynamic reload)? Or do you roll your own ClassLoader system? > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 03:32:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Mon, 20 Feb 2017 03:32:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365874#comment-13365874 ] Vincent Massol commented on CDI-114: ------------------------------------ {quote}So you allow that your users upload some jar which you then dynamically add to you Classpath? Or how does the XWiki container become aware of that new functionality? Does XWiki use OSGi (which would be suited for such a dynamic reload)? Or do you roll your own ClassLoader system?{quote} Yes admin users (or any user having the right permission) can install JAR extensions. XWiki doesn't use OSGI. We asked ourselves the question initially but it was way too compex and heavy so we decided that we wouldn't be able to have several versions of the same class with different versions in XWiki. We have a simple custom Component system to manage this (the main class is here if you're curious: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-default/src/main/java/org/xwiki/component/embed/EmbeddableComponentManager.java). We do have our own classloader (we have one per namespace - XWiki supports multiple wikis and a namespace is for example one wiki, to provide isolation per wiki). When a JAR extension is uninstalled, we recreate the classloader, removing the JAR URL. FYI: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-classloader/xwiki-platform-classloader-xwiki/src/main/java/org/xwiki/classloader/xwiki/internal/ContextNamespaceURLClassLoader.java and and https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-classloader/xwiki-commons-classloader-api/src/main/java/org/xwiki/classloader/URIClassLoader.java (this later one is just there to overcome JDK bugs/limitations). > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From manovotn at redhat.com Mon Feb 20 03:36:16 2017 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 20 Feb 2017 03:36:16 -0500 (EST) Subject: [cdi-dev] Extensions and spec-related observer method injection points question In-Reply-To: <6014FE91-679E-4EA9-918A-81B175652164@yahoo.de> References: <1834129599.24115657.1487311704201.JavaMail.zimbra@redhat.com> <6014FE91-679E-4EA9-918A-81B175652164@yahoo.de> Message-ID: <56861431.24600114.1487579776898.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Mark Struberg" > To: "Matej Novotny" > Sent: Sunday, February 19, 2017 9:05:30 PM > Subject: Re: [cdi-dev] Extensions and spec-related observer method injection points question > > > > > While you cannot do this, you can still get hold of BeanManager and use it > > to resolve your bean. > > No, you cannot. At least not before AfterBeanValidation. Obviously, but the question assumes the container is in the state where beans are resolvable. E.g., the question was meant more like "if I can resolve it with BM, why can't I use plain param. injection". > > LieGrue, > strub > > > > Am 17.02.2017 um 07:08 schrieb Matej Novotny : > > > > Hi, comment inline. > > > > ----- Original Message ----- > >> From: "Laird Nelson" > >> To: cdi-dev at lists.jboss.org > >> Sent: Thursday, February 16, 2017 11:11:41 PM > >> Subject: [cdi-dev] Extensions and spec-related observer method injection > >> points question > >> > >> This section ( > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ) says: > >> "If > >> other beans [other than the BeanManager ] are injected into an [portable] > >> extension?s observer methods, non-portable behavior results." > >> > >> Rephrased: a portable extension's observer methods must have a minimum of > >> one > >> parameter (the event being observed) and a maximum of two parameters (that > >> plus the BeanManager ), and none other if you want to stay truly portable. > > > > That's correct interpretation. > > > >> For true container lifecycle events, I understand this (you don't have > >> beans > >> to inject yet). But given that a bean must be provided by the container > >> for > >> a portable extension ( > >> http://docs.jboss.org/cdi/spec/2.0-PFD/cdi-spec.html#init_events ), > >> wouldn't > >> it be reasonable to permit extra injection points in a portable > >> extension's > >> non -container-lifecycle-event-observing observer methods? > >> > >> Concretely, I'd like to do this: > >> > >> // In my portable extension > >> private static final void doSomethingAtStartup(@Observes > >> @Initialized(ApplicationScoped.class) final Object event, final > >> Frobnicator > >> someBean) { > >> someBean.doSomething(); > >> } > > > > While you cannot do this, you can still get hold of BeanManager and use it > > to resolve your bean. > > > >> > >> ...but that would seem to be in violation of the specification. Could > >> someone > >> kindly explain why? > > > > Not really sure, perhaps Martin or Antoine can share the details. > > But I would say this could create quite some confusion if in some observer > > you could inject certain beans and in others you couldn't. > > Even in your sample, you can only inject AppScoped beans, so imagine you do > > such observer for, say, SessionScoped, what can you inject there? > > SessionScoped for sure, how about Req? Conversation? > > > >> > >> Thanks, > >> Best, > >> Laird > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> Note that for all code provided on this list, the provider licenses the > >> code > >> under the Apache License, Version 2 > >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > >> provided on this list, the provider waives all patent and other > >> intellectual > >> property rights inherent in such information. > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the > > code under the Apache License, Version 2 > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > > provided on this list, the provider waives all patent and other > > intellectual property rights inherent in such information. > > From issues at jboss.org Mon Feb 20 03:40:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 20 Feb 2017 03:40:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365884#comment-13365884 ] Mark Struberg commented on CDI-114: ----------------------------------- I see. So you have multiple 'apps' already running as each of your Wiki-namespace is essentially an own 'app' from a CDI pov, right? Would it be possible to bootstrap a new namespace instance and then just swapping out the original one with the freshly booted one? Looks much cleaner to me. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 03:47:01 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 20 Feb 2017 03:47:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365890#comment-13365890 ] Romain Manni-Bucau commented on CDI-114: ---------------------------------------- I do that in an app (except I have a single plugin but design is reusable for that case) starting N children CDI context inheriting from the parent one (which would be xwiki webapp). Child having access to the parent they can register services etc and still use CDI. Limitation is children are isolated but it can be a nice thing too for plugins. Would it be an option? CDI 2 with its se API should enable that since the managed instance (EE/Servlet) will start several SE contexts. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 03:51:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Mon, 20 Feb 2017 03:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365893#comment-13365893 ] Vincent Massol commented on CDI-114: ------------------------------------ {quote}So you have multiple 'apps' already running as each of your Wiki-namespace is essentially an own 'app' from a CDI pov, right?{quote} Not sure. Basically we have a Root Component Manager containing components seen by all namespaces (ie all wikis) and then each subwiki have their own Wiki Component Manager that contain components only seen by those subwikis (so in addition to the components located in the Root Component Manager). {quote}Would it be possible to bootstrap a new namespace instance and then just swapping out the original one with the freshly booted one? Looks much cleaner to me.{quote} So you're essentially saying the same thing as what was said earlier but with even most cost in term of performance, no? I.e recreate the classloaders (the root one and the wiki ones affected by the new component/bean being added) + reinitialize CDI (ie scanning and bean resolving), every time a new component is to be added at runtime. I don't know the performance of such an option but as I mentioned, we do have thousands and thousands of components/beans loaded, with some have initialization steps. IMO that would really be overkill in term of performance. Also in XWiki it's not that unfrequent to add new components at runtime. For example users can creates new macros as script in wiki pages and underneath they get registered as proper components/beans. Thanks > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 03:55:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 20 Feb 2017 03:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365896#comment-13365896 ] Romain Manni-Bucau commented on CDI-114: ---------------------------------------- [~vmassol] don't you mix xwiki component and cdi bean? a macro is not a Bean generally until you generate a custom class at runtime which in any case doesn't need CDI no? The producer option would still work but is still overkill to handle wiki macros since there is a manager in xwiki, no? > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 04:01:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Mon, 20 Feb 2017 04:01:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365902#comment-13365902 ] Vincent Massol commented on CDI-114: ------------------------------------ [~rmannibucau] I think xwiki component == cdi bean. Basically an XWiki component has a lifecycle (instantiation, injection, disposal) managed by the XWiki Component Manager. The goal of of using CDI for us would be to drop our Component Manager in favor of CDI (I guess it's the Bean Manager in CDI parlance but I'm a newbie so I could use the wrong terminology). Regarding the scripted macros, it's a special case. The way we handle this now is that the XWiki Component Manager has two ways to register a new component: by passing a Class/Type and it would instantiate it itself or by passing an existing instance (in which case, it'll not perform the instantiation but it'll still perform the populate/injections). As you mentioned, I guess that the equivalent in CDI is the Producer strategy. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 04:11:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 20 Feb 2017 04:11:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365909#comment-13365909 ] Romain Manni-Bucau commented on CDI-114: ---------------------------------------- If you know the type you can surely sort it out with producers but producers generally means 'do it yourself' which would lead to keeping the component manager more or less. However an extension can produce any bean based on a qualifier (see https://gist.github.com/antoinesd/3097661ca99fa61900fb but instead of Object you can use the xwiki-api/interfaces). Issue allowing runtime registration is you would need to reboot the container more or less bypassing the scanning only to validate injection points and to reinject all created beans to ensure the consistency. It is a lot of work and overhead at runtime for not that much gain since a manager is easy and fast for this kind of dynamic registration - even with subclassloaders. Hope this makes some sense > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 04:56:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Mon, 20 Feb 2017 04:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365957#comment-13365957 ] Vincent Massol commented on CDI-114: ------------------------------------ [~rmannibucau] If we need to keep our XWiki Component Manager then there's little interest in moving to CDI since (if I understand correctly) we would be able to use the CDI features only for core components that are registered statically at application boot time (and thus have two distinct Component models depending on whether you're coding a core extension or a non-core one). We're also reducing our number of core components to the maximum as time progresses to have the smallest possible core and all the rest are extracted into extensions. We currently have hundreds of extensions and this will grow even more in a very near future. So having 2 models is not a good idea IMO :) {quote}but producers generally means 'do it yourself'{quote} I don't understand this part. AFAIK you can use CDI constructs in producers, using injections, qualifiers, etc. Aren't there plenty of CDI apps that use producer constructs too without requiring to implement a Component Manager that would handle instantiation/injection? If the object created in the producers requires to be injected other beans, CDI doesn't provide any helper for that? Thanks > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 05:21:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 20 Feb 2017 05:21:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365979#comment-13365979 ] Romain Manni-Bucau commented on CDI-114: ---------------------------------------- producers are Bean so you can reuse CDI semantic (qualifiers etc) but not interceptors (until you use the factory cdi 2.0 introduces which is another part of the DIY) and other parts like post constuct etc as well (Unmanaged or equivalent). So whatever you do producers are for 3rd party integration and you keep all the work in this 3rd party. Until you add scanning and use default managed Beans you will not benefit of all CDI but just a subset like contexts, light lifecycle (produces/disposes), integration with other beans etc... Also it is unclear to me how CDI would fit your need since you have components but generally in extensions only and a set of selectable component depending a key where CDI will not help much (you still need a custom lookup aligned on your design so CDI or not is equivalent there which the Bean is managed by CDI which is done with an inherited BeanManager solution). Also note adding at runtime Beans still requires a classloader (CDI is not doing anything there) so this solution is actually low cost for you anyway. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 12:14:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Mon, 20 Feb 2017 12:14:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366436#comment-13366436 ] Vincent Massol commented on CDI-114: ------------------------------------ [~rmannibucau] You lost me with your last reply! :) AFAIK the XWiki Component Manager does exactly what Guice or CDI do (except that it handles runtime registration of beans). We have components both in the core and in extensions. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 12:20:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 20 Feb 2017 12:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366437#comment-13366437 ] Romain Manni-Bucau commented on CDI-114: ---------------------------------------- locally yes but in term of lifecycle not sure since xwiki is dynamic it needs to control what was injected before to be able to update which is not in Spring/Guice/CDI as basic features (always done through proxies and as an internal bean impl). So concretely if you do the hierarchic solution with a custom BeanManagerAggregator then you are fine and replaced the Map from your manager but you still need a dynamic runtime design "by design" which intends to breaks the startup validation and runtime safety. (that's what i meant) > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 12:31:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Mon, 20 Feb 2017 12:31:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366444#comment-13366444 ] Vincent Massol commented on CDI-114: ------------------------------------ {quote} since xwiki is dynamic it needs to control what was injected before to be able to update which is not in Spring/Guice/CDI as basic features (always done through proxies and as an internal bean impl).{quote} In XWiki we do lazy instantiation of components, i.e. we instantiate them when they are required (ie. when the ComponentManager.getInstance() is called or when a component needs to be injected in another component). However we do not control what was injected before. FTR XWiki only supports field injection. Thus if you register a new implementation of a Component role at runtime, all existing components that have been instantiated already are not modified. However when a component needs to have an aways up to date @Inject(ed) field, we use a Provider<> and the code using it calls get() on it to return the latest registered component instance from the Component Manager. BTW thanks for your replies! :) > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 12:35:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 20 Feb 2017 12:35:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366446#comment-13366446 ] Romain Manni-Bucau commented on CDI-114: ---------------------------------------- Hmm, does it means xwiki is leaking cause previously injected values can be unregistered ("remove extension")? Or did you mean you never inject the component by type but always Provider everywhere? If so you also do lazy validation which means you accept to start a not functional app cause of a missing component - CDI prevents it. Is that right? If so I fear you need something to "mock" until you can inject an actual component. Means you can refactor your code but not change it drastically cause of these rules. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Feb 20 16:29:00 2017 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Mon, 20 Feb 2017 16:29:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366540#comment-13366540 ] Laird Nelson commented on CDI-114: ---------------------------------- ([~vmassol], you may wish to use [HK2|https://hk2.java.net/2.5.0-b34/] instead of CDI in these cases as it is [designed for this sort of dynamic situation|https://hk2.java.net/2.5.0-b34/apidocs/org/glassfish/hk2/api/DynamicConfiguration.html#addActiveDescriptor(java.lang.Class)]. I personally prefer the static nature of CDI and am very glad that the relationships between beans are set up in advance, and consider this static bias part of the nature of CDI. HK2 is a much more freewheeling dependency injection framework with some similar features; it may more closely match your requirements.) > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 07:18:00 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Tue, 21 Feb 2017 07:18:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366835#comment-13366835 ] Vincent Massol commented on CDI-114: ------------------------------------ Hi [~ljnelson]. Thanks for mentioning HK2, I didn't know about it. I'll check it out. At first glance, it look very similar to what we have implemented in XWiki. I'll read more about it. However I'm not sure it would justify the effort to switch to it. We don't have any problem with our custom Component Manager and it's low cost maintenance now. What would improve the XWiki technology stack would be to move to a "standard" DI framework. CDI would probably have been the most standard option if it had supported runtime addition of beans. Guice would be another possibility but I'd need to check how dynamicity could be implemented (I remember reading that it was possible). Thanks > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 07:22:01 2017 From: issues at jboss.org (Vincent Massol (JIRA)) Date: Tue, 21 Feb 2017 07:22:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366843#comment-13366843 ] Vincent Massol commented on CDI-114: ------------------------------------ {quote}Hmm, does it means xwiki is leaking cause previously injected values can be unregistered ("remove extension")?{quote} Actually I don't know how we would behave if you remove at runtime a component that's been previously injected in another component. In theory yes there should be a problem.In practice in 12 years of XWiki I've never seen this happen. {quote}Or did you mean you never inject the component by type but always Provider everywhere? {quote} No we don't do that systematically, although we recommend it. It's done mostly at places where it's important to be able to use the latest registered component for a given role. {quote}If so you also do lazy validation which means you accept to start a not functional app cause of a missing component - CDI prevents it. Is that right?{quote} Yes we do allow this. Thanks > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Feb 21 12:12:01 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 21 Feb 2017 12:12:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) InterceptionFactory parameter type vs type of instance to intercept In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-686: ---------------------------------------- Summary: InterceptionFactory parameter type vs type of instance to intercept Key: CDI-686 URL: https://issues.jboss.org/browse/CDI-686 Project: CDI Specification Issues Issue Type: Clarification Reporter: Antoine Sabot-Durand It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 08:15:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 22 Feb 2017 08:15:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-686: ------------------------------------- Summary: Could InterceptionFactory accept an interface as type parameter (was: InterceptionFactory parameter type vs type of instance to intercept) > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 08:15:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 22 Feb 2017 08:15:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-686: ------------------------------------- Affects Version/s: 2.0 .Final > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 14:58:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 22 Feb 2017 14:58:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-686: ------------------------------------- Description: If you take this code: {code:java} @Produces public List produceList(InterceptionFactory> interceptionFactory) { interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { if (m.getJavaMember().getName().equals("add") && m.getJavaMember().getParameterCount() == 1) { return true; } return false; }).findFirst().get().add(Monitor.Literal.INSTANCE); return interceptionFactory.createInterceptedInstance(new ArrayList<>()); } {code} Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. was:It's not clear what type of instance an InterceptionFactory should accept vs the parameterized type and restriction regarding them. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Feb 22 15:01:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 22 Feb 2017 15:01:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367756#comment-13367756 ] Antoine Sabot-Durand commented on CDI-686: ------------------------------------------ I suggest that we make this usage non portable to let implementation decide and let the door open for a future specification. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 03:30:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 23 Feb 2017 03:30:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367897#comment-13367897 ] Martin Kouba commented on CDI-686: ---------------------------------- +1 for non-portable behavior. I don't think it makes much sense to support interfaces here. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 03:54:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 23 Feb 2017 03:54:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367912#comment-13367912 ] Romain Manni-Bucau commented on CDI-686: ---------------------------------------- Hmm, isnt one of the goals of this factory to make custom beans (Bean<>) easily integrated with CDI interceptors? If so it is common to have java.lang.reflect based proxies there (see deltaspike ones for instance) and it is very nice and smooth to be able to reuse cdi there. Here a trivial but obvious example: take a repository like proxy based implementation, don't you want to integrate it with jcache which has its own interceptor without coding more than the factory itself? Today it requires to either be bound to a jcache implementation or reimplement the interceptor chain logic from the container which is a pain. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 04:51:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 23 Feb 2017 04:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367952#comment-13367952 ] Antoine Sabot-Durand commented on CDI-686: ------------------------------------------ [~rmannibucau]I'm not sure to understand your point. {{InterceptionFactory.createInterceptedInstance()}} requires an object instance to be intercepted. This proposal doesn't prevent its usage in a custom {{Bean}} since in {{InterceptionFactory}}, {{U}} is related to instances class and not to beans types (even if they are linked of course). > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 04:51:00 2017 From: issues at jboss.org (Thomas Andraschko (JIRA)) Date: Thu, 23 Feb 2017 04:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367953#comment-13367953 ] Thomas Andraschko commented on CDI-686: --------------------------------------- +1 romain. Same for abstract classes. Mabye it would be great if the CDI API would allow the same features as the DS PartialBean module. Shoudln't be that hard. AFAIR the code is almost already availble in OWB, we would just need a nice API (like introducing a @PartialBeanBinding). > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 05:10:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 23 Feb 2017 05:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367974#comment-13367974 ] Romain Manni-Bucau commented on CDI-686: ---------------------------------------- [~antoinesabot-durand] how is it supposed to work with an API which doesn't use @Produces and doesn't have a concrete implementation but just a Proxy instance? > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 09:51:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 23 Feb 2017 09:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368235#comment-13368235 ] Martin Kouba commented on CDI-686: ---------------------------------- I think I understand the use case described by [~rmannibucau] and [~tandraschko], e.g. somethig like: {code:java} interface MyService {} class MyServiceProducer { @Produces MyService produce(InterceptionFactory factory, ServiceLocator locator) { factory.configure().add(Monitor.Literal.INSTANCE); // Lookup a MyService implementation... return factory.createInterceptedInstance(locator.lookup(MyService.class)); } } {code} However, I'm afraid it's too late for this kind of discussions. Since we would have to carefully adapt the inheritance rules (as defined in "4. Inheritance and specialization") for this particular use case. Note that _"Type-level metadata is never inherited from interfaces implemented by a bean."_. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 09:55:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 23 Feb 2017 09:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368241#comment-13368241 ] Romain Manni-Bucau commented on CDI-686: ---------------------------------------- You can also consider: {code} // pseudo code MyBean implements Bean { T create(CC context) { return factory.createInterceptedInstance(Proxy.newProxyInstance(...)); } } {code} Which is way more commont than the producer case IMHO - at least from the code I encountered until now. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 10:22:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 23 Feb 2017 10:22:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368267#comment-13368267 ] Antoine Sabot-Durand commented on CDI-686: ------------------------------------------ Ok, got it. But as Martin and I said it's a bit late to work on that without risking making error in standardisation. So I still suggest that we make it non portable to allow us to cleanly specify it in the future. On the Weld side, we'll probably add this support (that doesn't exist right now) to allow these use case. > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 10:25:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 23 Feb 2017 10:25:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368275#comment-13368275 ] Romain Manni-Bucau commented on CDI-686: ---------------------------------------- is that so hard? I mean, I don't think we need a CDI rule but just a standard java one where you can "cast" the instance since it is out of CDI matching rules world, no? Or do you want to limit to the "injected" generic type? > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 10:51:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 23 Feb 2017 10:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368313#comment-13368313 ] Martin Kouba commented on CDI-686: ---------------------------------- What's the _"injected" generic type_? > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Feb 23 11:01:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 23 Feb 2017 11:01:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368322#comment-13368322 ] Romain Manni-Bucau commented on CDI-686: ---------------------------------------- was referring to the producer parameter but tend to think the factory doesnt care much and can use the passed types blindly > Could InterceptionFactory accept an interface as type parameter > --------------------------------------------------------------- > > Key: CDI-686 > URL: https://issues.jboss.org/browse/CDI-686 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > If you take this code: > {code:java} > @Produces > public List produceList(InterceptionFactory> interceptionFactory) { > interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> { > if (m.getJavaMember().getName().equals("add") > && m.getJavaMember().getParameterCount() == 1) { > return true; > } > return false; > }).findFirst().get().add(Monitor.Literal.INSTANCE); > return interceptionFactory.createInterceptedInstance(new ArrayList<>()); > } > {code} > Parameterized type for injected {{InterceptionFactory}} is an interface {{List}}, so when calling {{configure()}}, user will work with an {{AnnotatedTypeConfigurator>}} to apply interceptor binding. > In a standard interceptor usage, interceptor binding on interface are ignored (even if they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be confusing for some user. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Thu Feb 23 15:41:49 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Thu, 23 Feb 2017 20:41:49 +0000 Subject: [cdi-dev] Identify a Bean as synthetic? Message-ID: I haven't thought this through yet but I wonder if it would be helpful to mark a Bean as synthetic or not?i.e. discovered by means of the "normal" bean discovery process, or programmatically added by a portable extension. I was mentally working through what it might take to write up a sort of CDI reporting mechanism?something that would report on what beans where found, where they came from, what interceptors are enabled and why, etc. etc. etc. and realized one axis of this would be whether a portable extension was involved with certain beans or not. Should I file an enhancement/feature request, or is this something that was already debated and turned away at some point in the past? Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170223/bd55eab1/attachment.html From manovotn at redhat.com Fri Feb 24 01:51:22 2017 From: manovotn at redhat.com (Matej Novotny) Date: Fri, 24 Feb 2017 01:51:22 -0500 (EST) Subject: [cdi-dev] Identify a Bean as synthetic? In-Reply-To: References: Message-ID: <1999317814.26281482.1487919082927.JavaMail.zimbra@redhat.com> Not sure I follow here, but as it is now, you can leverage things like ProcessSyntheticAnnotatedType, ProcessSyntheticBean etc. You can have an observer for those and get notified of added AT, Bean, OM,... Is that it? Or did you have something else in mind? Matej ----- Original Message ----- > From: "Laird Nelson" > To: cdi-dev at lists.jboss.org > Sent: Thursday, February 23, 2017 9:41:49 PM > Subject: [cdi-dev] Identify a Bean as synthetic? > > I haven't thought this through yet but I wonder if it would be helpful to > mark a Bean as synthetic or not?i.e. discovered by means of the "normal" > bean discovery process, or programmatically added by a portable extension. > > I was mentally working through what it might take to write up a sort of CDI > reporting mechanism?something that would report on what beans where found, > where they came from, what interceptors are enabled and why, etc. etc. etc. > and realized one axis of this would be whether a portable extension was > involved with certain beans or not. > > Should I file an enhancement/feature request, or is this something that was > already debated and turned away at some point in the past? > > Best, > Laird > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From mkouba at redhat.com Fri Feb 24 02:27:55 2017 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 24 Feb 2017 08:27:55 +0100 Subject: [cdi-dev] Identify a Bean as synthetic? In-Reply-To: References: Message-ID: <00e13b4a-a760-ddbc-37c1-08ae681965da@redhat.com> Dne 23.2.2017 v 21:41 Laird Nelson napsal(a): > I haven't thought this through yet but I wonder if it would be helpful > to mark a Bean as synthetic or not?i.e. discovered by means of the > "normal" bean discovery process, or programmatically added by a portable > extension. I'm not sure it's worth specification. As Matej mentioned the ProcessSyntheticBean event should do the trick. From the impl point of view, it would be easier to mark the "discovered" beans, ie. implement some marker interface - for synthetic beans the container would have to wrap the provided Bean impls. > > I was mentally working through what it might take to write up a sort of > CDI reporting mechanism?something that would report on what beans where > found, where they came from, what interceptors are enabled and why, etc. > etc. etc. and realized one axis of this would be whether a portable > extension was involved with certain beans or not. Something like Weld Probe [1], cdeye [2] or VisualEE [3]? > > Should I file an enhancement/feature request, or is this something that > was already debated and turned away at some point in the past? > > Best, > Laird > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > [1] http://probe-weld.itos.redhat.com/weld-numberguess/weld-probe http://docs.jboss.org/weld/reference/latest/en-US/html/devmode.html [2] https://github.com/astefanutti/cdeye [3] https://github.com/Thomas-S-B/visualee/ From ljnelson at gmail.com Fri Feb 24 11:57:04 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Fri, 24 Feb 2017 16:57:04 +0000 Subject: [cdi-dev] Identify a Bean as synthetic? In-Reply-To: <00e13b4a-a760-ddbc-37c1-08ae681965da@redhat.com> References: <00e13b4a-a760-ddbc-37c1-08ae681965da@redhat.com> Message-ID: On Thu, Feb 23, 2017 at 11:27 PM Martin Kouba wrote: > Dne 23.2.2017 v 21:41 Laird Nelson napsal(a): > > I haven't thought this through yet but I wonder if it would be helpful > > to mark a Bean as synthetic or not?i.e. discovered by means of the > > "normal" bean discovery process, or programmatically added by a portable > > extension. > > I'm not sure it's worth specification. As Matej mentioned the > ProcessSyntheticBean event should do the trick. > Yes; I just had completely forgotten about that. > > I was mentally working through what it might take to write up a sort of > > CDI reporting mechanism?something that would report on what beans where > > found, where they came from, what interceptors are enabled and why, etc. > > etc. etc. and realized one axis of this would be whether a portable > > extension was involved with certain beans or not. > > Something like Weld Probe [1], cdeye [2] or VisualEE [3]? > Yes (thanks for the pointers; only knew about two of them), but much simpler and limited in scope. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170224/331bc86d/attachment.html From issues at jboss.org Tue Feb 28 10:38:00 2017 From: issues at jboss.org (Samba Kolusu (JIRA)) Date: Tue, 28 Feb 2017 10:38:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-114) Allow registration of beans at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370451#comment-13370451 ] Samba Kolusu commented on CDI-114: ---------------------------------- let me put this issue in a different context: (1) let us say an application is deployed with three CORE modules that are essentials and cannot be disabled or removed, each having their own named CDI beans, which may depend on other such beans from the other two core modules. this setup works perfectly as all the modules (and CDI beans, interceptors, qualifiers, decorators, etc) are always loaded , and at deployment (2) a new module is installed into this system at runtime - with the following CDI usage: inject existing CDI beans, supplied by one or more of the always present core modules, into its own injectable classes like Servlets, JSF backing beans, transaction Services, etc. i suppose this should not be an issue at all, since the new module is only trying to use existing CDI components. if for example for Events that need to be fired, the newly registered CDI components from the installed module (plugin, for clarity) can be added as EventListeners or interceptors during bean registration. the core modules shall never depend on the additional modules. it is only the CDI components from additional modules that may listen to or intercept the events and method invocations of CDI components from core modules. ---- what is the problem in supporting this feature? (3) let us say module-x and module-y are deployed as additional modules, and module-y specified dependency on module-x because one or more of the CDI component in module-y is using or listening or intercepting one or more of the CDI components from module-x. in this case - the module framework will not let the installation of module-y if module-x is not installed; similarly, the framework will not let the uninstallation of module-x without the uninstallation of module-y. so, we can always be sure that the CDI components required by module-y are always present in the application because when module-y is there, the module-x shall always be there. at no point in time, a CDI component in module-x can refer to (depend on) a CDI component of module-y. that dependency management is the responsibility of the module framework, if it fails there, it is not the problem of CDI. why can't this be supported? (4) i guess you could be thinking about a scenario where one CDI component from module-x depends on other CDI compoent of module-y while another CDI component of module-y depends on yet another CDI component of module-x.... i.e. cyclical dependency of modules... i agree that makes it much more complex, and require checking boundaries too often-- but why can't a well-defined dependency graph be supported? all that is needed is registering the CDI components (by component, i mean bean/interceptor/qualifier/producer/etc) at runtime, and broadcasting the events (including method invocation - for interceptors) to runtime registered CDI components. what is so dangerous in this? as a realistic use case : suppose a web app is deployed with some core set of JPA Entities, JSF backing beans, JSF pages, CDI Transaction beans that may offer REST services too (because EJB container do not allow dynamic adding of beans, we rely solely on CDI) . now into this system, a new module gets installed that brings in new JPA entities, JSF backing beans, JSF pages, its own CDI transactional components, etc. now, any of the CDI components (including backing beans) may like to listen for or depend or intercept any of CDI components deployed at startup (or installed before). why can?t this be achieved since the previously installed CDI components can never depend on the newly installed CDI components? what problems do you see in this? in fact, we can easily uninstall this newly installed module and remove all of its CDI components with out any impact to the core web app system that was deployed initially. ? all that is needed is to track what came in new, and which new ones are listening to or intercepting around which old ones. refusing to implement this feature because improper usage may cause unpredictable errors is like saying synchronized key word cannot be supported because its improper use leads to deadlocks in multi-threaded systems. > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: TBD > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v7.2.3#72005)