I'll explain the architecture of the rewrite so you can understand how it works. The old prototype had lots of different elements scattered around which made it not very easy to implement things. I've replaced them with essentially two main items, OSGiBundleState and OSGiServiceState which then have "proxies/facades" for the standard OSGi api. BUNDLES The OSGiBundleState is little more than a facade over a top level DeploymentUnit. Every deployment goes through the OSGiBundleStateDeployer which creates an OSGiBundleState wrapper for that deployment. They are all registered in an OSGiBundleManager such that the bundle query stuff can work - and other system level data/services can be configured/reached on that item. The OSGiBundleState is added as an attachment to the deployment. This doesn't mean it is an OSGi deployment (that is controlled by whether the deployment has an OSGiMetaData attachment). What it means is that you can write other deployers like the OSGiBundleActivatorDeployer that can see what the Bundle is for a deployment. When we come to do the service layer properly, we should also add the OSGiBundleState to the DEPLOYMENT MDR scope so any MC context can know which "bundle" it belongs to. The OSGiBundleState has two "facades" the standard Bundle and the BundleContext interfaces. Of course, there's a special implementation of the OSGiBundleState for the "system bundle" which works slightly differently. SERVICES The service layer is not so well integrated with the MC. It does just enough to be "OSGi compliant" (of course that's not yet tested). So this is at the moment very simple. The OSGiServiceState which should eventually turn into an MC context implementation has two "facades", the standard ServiceRegistration and ServiceReference interfaces. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249955#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...