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