Out of curiosity. What is your business use case for switch the components on and off at deployment time (or even at runtime)?
Maybe with a more concrete example there are better ideas.

Christian

On 16.02.2016 23:59, Alexander Klimetschek wrote:
On 16.02.2016, at 13:03, BJ Hargrave <hargr...@us.ibm.com> wrote:
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).
[X]

An enabled component must then be satisfied. That is, any required 
configuration is available and any required services are available.
I think what we are looking for is a standardized layer in between – marked 
with [X] –, to have a deployer control if the component is on or off, clearly 
separate from the other layers.

A bundle might provide multiple components that individually should be set to 
on or off, hence bundle active/installed is not useful. Component description 
as part of the bundle is something that cannot be changed by a deployer. 
Satisfaction of service dependencies is a concern external to the component. 
The required configuration approach requires the developer to make that 
decision upfront by include the required config setting in the component 
description, and it removes all of the standard configuration values if a 
deployer decides to delete the config. (Sorry if I am repeating, just wanted to 
summarize it again).

Cheers,
Alex
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev


--
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

Reply via email to