Hi,
Am 30.04.2012 um 20:35 schrieb David Jencks:
> The compendium 4.2 112.5.1 says
>
> The enableComponent and disableComponent methods must return after changing
> the enabled state of the named component. Any actions that result from this,
> such as activating or deactivating a component configura- tion, must occur
> asynchronously to the method call. Therefore a component can disable itself.
>
> However in ACM.disable we have
>
> public final void enable()
> {
> enableInternal();
> activateInternal();
> }
>
> public final void disable()
> {
> deactivateInternal( ComponentConstants.DEACTIVATION_REASON_DISABLED );
> disableInternal();
> }
>
> which doesn't look asynchronous.
>
> Anyone have ideas on what's going on? I admit I don't understand what the
> spec hopes to gain with the async requirement as it appears to allow a
> disabled active component to hang around for an arbitrarily long time.
>
> If everyone thinks this is a bad requirement, what has been done to fix the
> spec?
I don't think the requirement is bad. And in fact our implementation implements
the spec almost correctly.
The ComponentContextImpl.enableComponent and .disableComponent delegate to
BundleComponentActivator.enableComponent and .disableComponent. Those methods
schedule enablement and disablement for asynchronous processing. So in this
respect the implementation is correct.
The minor incorrectness is that the component is not explicitly marked as
enabled or disabled because we do not currently track such state in addition to
the actual component state.
Regards
Felix
>
> thanks
> david jencks
>
>
>
