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