Stuart, I implement the first cut of this as we talked about. The DeferredModuleUseProcessor adds a the module service as a dependency on the next phase, which is FISRT_MODULE_USE. This is actually something I previously already did for resolved bundles - now I do it always in this DUP. The DeploymentUnitPhaseService makes Phase.FISRT_MODULE_USE passive if it sees explicitly named services in Attachments.DEFERRED_MODULE_DEPENDENCIES The processing is currently limited to OSGi only and this patch should not effect other deployment types. The OSGi testsuite passes completely with a few deployments hanging in Phase.FISRT_MODULE_USE before they triggered to proceed by an explicit API call which resolves the bundle and hance makes the module service available. TODO: * Think about whether Phase.FISRT_MODULE_USE should always depend on the Module service * Remove all module == null checks in FISRT_MODULE_USE DUPs and after. cheers --thomas

The use of the SVH probably needs more work. Currently, there are multiple paths that could make a bundle resolve and hence cause the processing of DUP chain. If there is an error in a post module phase it's not clear how that would be handled. Specifically, a rollback should not cause the deployment to get undeployed. I'll think of a few tests about this. --thomas On 09/25/2012 04:26 PM, Thomas Diesler wrote: > https://issues.jboss.org/browse/AS7-5477 > > https://github.com/tdiesler/jboss-as/tree/as5477 > > On 09/25/2012 04:24 PM, Thomas Diesler wrote: >> Stuart, >> >> I implement the first cut of this as we talked about. >> >> The DeferredModuleUseProcessor adds a the module service as a dependency >> on the next phase, which is FISRT_MODULE_USE. This is actually something >> I previously already did for resolved bundles - now I do it always in >> this DUP. >> >> The DeploymentUnitPhaseService makes Phase.FISRT_MODULE_USE passive if >> it sees explicitly named services in >> Attachments.DEFERRED_MODULE_DEPENDENCIES >> >> The processing is currently limited to OSGi only and this patch should >> not effect other deployment types. The OSGi testsuite passes completely >> with a few deployments hanging in Phase.FISRT_MODULE_USE before they >> triggered to proceed by an explicit API call which resolves the bundle >> and hance makes the module service available. >> >> TODO: >> >> * Think about whether Phase.FISRT_MODULE_USE should always depend on the >> Module service >> * Remove all module == null checks in FISRT_MODULE_USE DUPs and after. >> >> cheers >> --thomas >>