[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Samba Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Samba Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Laird Nelson (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Samba Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Samba Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Samba Siva Rao Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
[JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API
by Samba Siva Rao Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-682?page=com.atlassian.jira.plugin.sy... ]
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)
7 years, 10 months
