Samba Kolusu commented on CDI-114:
let me put this issue in a different context:
(1) let us say an application is deployed with three CORE modules that are essentials and
cannot be disabled or removed, each having their own named CDI beans, which may depend on
other such beans from the other two core modules.
this setup works perfectly as all the modules (and CDI beans, interceptors, qualifiers,
decorators, etc) are always loaded , and at deployment
(2) a new module is installed into this system at runtime - with the following CDI usage:
inject existing CDI beans, supplied by one or more of the always present core modules,
into its own injectable classes like Servlets, JSF backing beans, transaction Services,
etc. i suppose this should not be an issue at all, since the new module is only trying to
use existing CDI components. if for example for Events that need to be fired, the newly
registered CDI components from the installed module (plugin, for clarity) can be added as
EventListeners or interceptors during bean registration. the core modules shall never
depend on the additional modules. it is only the CDI components from additional modules
that may listen to or intercept the events and method invocations of CDI components from
core modules. ---- what is the problem in supporting this feature?
(3) let us say module-x and module-y are deployed as additional modules, and module-y
specified dependency on module-x because one or more of the CDI component in module-y is
using or listening or intercepting one or more of the CDI components from module-x. in
this case - the module framework will not let the installation of module-y if module-x is
not installed; similarly, the framework will not let the uninstallation of module-x
without the uninstallation of module-y. so, we can always be sure that the CDI components
required by module-y are always present in the application because when module-y is there,
the module-x shall always be there. at no point in time, a CDI component in module-x can
refer to (depend on) a CDI component of module-y. that dependency management is the
responsibility of the module framework, if it fails there, it is not the problem of CDI.
why can't this be supported?
(4) i guess you could be thinking about a scenario where one CDI component from module-x
depends on other CDI compoent of module-y while another CDI component of module-y depends
on yet another CDI component of module-x.... i.e. cyclical dependency of modules... i
agree that makes it much more complex, and require checking boundaries too often-- but why
can't a well-defined dependency graph be supported?
all that is needed is registering the CDI components (by component, i mean
bean/interceptor/qualifier/producer/etc) at runtime, and broadcasting the events
(including method invocation - for interceptors) to runtime registered CDI components.
what is so dangerous in this?
as a realistic use case :
suppose a web app is deployed with some core set of JPA Entities, JSF backing beans, JSF
pages, CDI Transaction beans that may offer REST services too (because EJB container do
not allow dynamic adding of beans, we rely solely on CDI) . now into this system, a new
module gets installed that brings in new JPA entities, JSF backing beans, JSF pages, its
own CDI transactional components, etc. now, any of the CDI components (including backing
beans) may like to listen for or depend or intercept any of CDI components deployed at
startup (or installed before). why can’t this be achieved since the previously installed
CDI components can never depend on the newly installed CDI components? what problems do
you see in this? in fact, we can easily uninstall this newly installed module and remove
all of its CDI components with out any impact to the core web app system that was deployed
initially. — all that is needed is to track what came in new, and which new ones are
listening to or intercepting around which old ones. refusing to implement this feature
because improper usage may cause unpredictable errors is like saying synchronized key word
cannot be supported because its improper use leads to deadlocks in multi-threaded systems.
Allow registration of beans at runtime
Project: CDI Specification Issues
Issue Type: Feature Request
Affects Versions: 1.0
Reporter: Vincent Massol
Fix For: TBD
I have use cases where I need to register a bean dynamically at runtime (see the forum
reference link for a detailed description of the use case).
This message was sent by Atlassian JIRA