[jboss-as7-dev] [AS7-5477] Allow processing of the module phase to be deferred

Stuart Douglas stuart.w.douglas at gmail.com
Tue Sep 25 22:46:37 EDT 2012


So I have been thinking about this a bit today, and I don't really like 
the approach of making the phase passive.

I think it should actually be a start type of NEVER, and it will require 
an explicit start operation from the OSGi framework (or some other 
client) in order to actually start to deferred deployment.

This start operation would be able to report back on the success or 
failure via a SVH, and it would then be up to OSGI how to handle the 
error. I would think that in the error case you would probably want to 
undeploy, as there is not really anything else you can do.

WDYT?

Stuart

Thomas Diesler wrote:
> 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
>>>
>


More information about the jboss-as7-dev mailing list