[cdi-dev] [JBoss JIRA] (CDI-682) Allow unregistration of CDI beans at run time, through API

[Samba Kolusu (JIRA)]

    [ 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)