I do not see a mix of concerns here. There is component enablement and there is component satisfaction.
A component must be first be enabled which requires it to live in a bundle which is started and also to have the component description enabled (either via the declaration or the API).
An enabled component must then be satisfied. That is, any required configuration is available and any required services are available.
So these are layers, not concern mixing.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
----- Original message -----
From: Alexander Klimetschek <aklim...@adobe.com>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: Re: [osgi-dev] Declarative disabling of a DS component
Date: Tue, Feb 16, 2016 3:55 PM
It would also be interesting if this was previously discussed and if yes, what arguments spoke against it (our resident osgi experts mentioned this might have been a topic before).
Thanks,
Alex
> On 15.02.2016, at 08:22, Christian Schneider <ch...@die-schneider.net> wrote:
>
> Yes .. it is a bit of a mix of concerns but as far as I know it is the only option at the moment.
>
> Christian
>
> On 15.02.2016 17:13, Justin Edelson wrote:
>> Hi Christian,
>> Per my original email, there are some limitations of the require policy. Further it seems to me that this is a bit of a mix of concerns. It shouldn't be ConfigAdmin's job to enable/disable components and, in point of fact, that isn't actually what the require policy does. It marks a component as "unsatified" which is not semantically the same as "disabled" (even if the result is the same).
>>
>> Regards,
>> Justin
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
