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

[Samba Siva Rao Kolusu (JIRA)]

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