Re: [jboss-as7-dev] [AS7-5477] Allow processing of the module phase to be deferred
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
>>