I think we're talking at cross purposes. Let's start again from scratch with the requirements. What is required is to be able to do "service tracking". So we add a "ServiceTracker" to the MDR which for deployments will be in the deployment level (really the application/top level deployment) for others it will be as you say a default one at the Server level, what osgi calls the "SystemBundle". You can imagine others might choose to track at some other level. e.g. for JavaEE we might choose to track at sub-deployment level, what MDR confusingly calls the deployment level. :-) When you do any type of injection (or the api is invoked from somewhere else) this should invoke the equivalent of get/unget of the ServiceTracker for that context. In MC terms that is getTarget() for get. But we don't currently invoke an ungetTarget() at "uninjection" so that needs doing. Of course the OSGiServiceStates become ControllerContexts and delegate to the same api. Once that is done, the queries can go through the ServiceTracker at the relevant level. The deployment level for normal OSGiBundleState and the server level for the SystemBundle. You still need a "global" list of services for the getXXXServiceXXX() queries. That should primarily be based on an index by class (it doesn't have to be its a performance optimization and only available when you have been asked to query by class). But once you've subsetted by class then you do a "read and skip" over those contexts to locate the ones that match any passed filter on the properties (instance level MDR). We might choose to expand the queries to include things other than class and filter for out private api, but this won't be available using the OSGi api. Don't think of this as just for OSGi. It is something that is available for other deployments as well. It's just motivated by OSGi since it comes from their api. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265098#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...