The NPE in InterceptorAnnotationProcessor.processComponentConfig is a bug and would need to get fixed first. In the past we had a ton of these issues. It comes from DUPs in the INSTALL phase making the assumption that there is a valid classloader/module associated with the deployment. This would be the case for all javaee deployments, but not necessarily for OSGi bundle deployments. A bundle deployment gets its classloader/module associated when it gets resolved. This does not necessarily happen at deploy time. Specifically, a resolve/start attempt is made when the autoStart flag on the Deployment is true. This is the default for non-fragments. However, have a look at BundleDeploymentProcessor for the various cases when autoStart is turned off. When you use BundleContext.install() the bundle is deployed through the management API (and not directly onto the framework) and hence runs through all the DUPs - this is handled by BundleInstallIntegration. For this case we obviously need to turn autoStart off because we only want the bundle to reach INSTALL state. The REFLECTION_INDEX is (AFAIK) an index that you can use to quickly lookup the types that implement a given annotation. There may be other uses too. The issue you are describing here comes from the general problem that OSGi and AS7 deployment phases are still not aligned. Generally apart from the naming confusion it would be necessary to have the ability to associate a stop phase with a deployment. For example stopPhase=REGISTER in which case the deployment would run through the phases up until REGISTER, but not further. An external trigger could be used to make it proceed through the other phases. *Actually* you don't need OSGi to run into this problem. If moduleA has a dependency on moduleB and you deploy moduleA you would see a similar issue related to this ordering and deployment lifecycle issue. I have prototypes that address these issues - after Alpha1 I'll take another stab. cheers -thomas On 07/25/2012 04:12 PM, David Bosschaert wrote: -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler JBoss OSGi Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx