]
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