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.
On 09/25/2012 04:26 PM, Thomas Diesler wrote:
On 09/25/2012 04:24 PM, Thomas Diesler wrote:
> 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
> 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.
> * 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.
JBoss OSGi Lead
JBoss, a division of Red Hat