Folks, the patch set is ready for review: #3117 This functionality is constraint to osgi only. If there is a bundle deployment that cannot resolve (possibly the user said so) I'll set the FIRST_MODULE_USE phase to initial NEVER. The deployment hangs in the configure module phase and awaits an external trigger. The bundle is metadata valid and in state Bundle.INSTALLED. A Bundle.start() operation sets up a service tracker and activates the deferred phase. this only succeeds if the bundle can get resolved and has a Module attached. The bundle deployment proceeds through the phases and activates. If there is failure in any of the tracked services Bundle.start() will fail with the root cause and the FIRST_MODULE_USE phase is set back to NEVER - this is a partial undeploy. After correcting the problem the user can re-attempt a Bundle.start(). In case of bundles contained in an EAR, I set the FIRST_MODULE_USE phase of the EAR to PASSIVE. It is possible that some DUPs dont support repeated deploy calls (yet). In which case they use

DeploymentUtils.skipRepeatedActivation(deploymentUnit, 0)

with the number of attempts they do support (see ModuleJndiBindingProcessor). Some techs that support bundle deployments (i.e. web,jaxrs,jaxws,jpa,cdi,ejb3) may still need more work to support restart after failure. This can be done on a case by case basis. Generally DUPs can now assume that a module is attached for a host bundle deployment. In case of an unresolved bundle deployment we don't miss the work they do any more. However, we still need the module not null checks because bundle fragment deployments never have a module. They attach to a host and use that class loader. Thoughts? cheers --thomas

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx