"adrian(a)jboss.org" wrote : | The service tracking needs moving into the MC as part of this integration. | The issue is what you track against. | Actually I had more fine grained tracking in mind. Like I tried to explain, and I probably failed, I was thinking about OSGi service unget callbacks. In MC we simply nullify injections at un-configure. But in case the injected service is an OSGi service, we should also somehow invoke the unget. We need something like ValueMetaData:release, which in InjectionMetaData impl it would call ControllerContext::releaseTarget. Or something like that ... "adrian(a)jboss.org" wrote : | As part of the OSGi stuff, I've made the DeploymentUnit part of the MDR's | deployment level metadata. You should extend this concept so that the | dependency project can look for a "ServiceTracker" in the MDR rather than | a DeploymentUnit. The deployers project would then add the ServiceTracker | attachment by the default to the deployment level metadata. | | If there is no such data (e.g. for MC contexts created by the bootstrap) | then you should track against the "SystemBundle", i.e. a shared default deployment. | | The OSGi stuff would then just delegate to those items for service tracking | instead of having to do it itself in the AbstractBundleState. | What's the use of this vs. KernelController's contextual tracking? Since this would already be part of dependency whereas that is part of kernel? If we use this, what would we gain by putting this in deployment level instead of server level - which should be available for bootstrap beans as well? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265095#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...