[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] 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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)