DS is already declarative. What additional declarations are you thinking of? Where would a "deployment' declaration come from? If the deployment declaration disabled a component, how would the component later become enabled? Through API calls? How would the deployer create and deploy deployment declarations?
I am a bit confused as to how you think this would work.
It seems to me the best way for the deployer to "disable" a component is to not install or start the bundle holding the component if the component is not relevant to the system. Remember, the set of installed/started bundles is a significant part of the "configuration" of a system and the deployer is in complete control over the set of installed/started bundles.
I think the best solution is to properly partition the components into bundles such the deployer can decide whether to install and/or start a certain bundle holding the components that should or should not be enabled.
--
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: Justin Edelson <jus...@justinedelson.com>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: [osgi-dev] Declarative disabling of a DS component
Date: Thu, Feb 11, 2016 12:53 PM
Hi,I see a real need in the DS specification for a standardized way to declaratively disable DS components by default *at deploy time* whereas the current model (please correct me if I'm wrong) only allows for components to be disabled by default at packaging time.The primary use case I'm concerned about is where we provide an OSGi-based application which gets deployed into a variety of environments (I'm speaking specifically about Adobe Experience Manager, but I don't believe that this problem is necessarily specific to our product), some of which are managed by us and others are managed by our customers. The application is composed of thousands of DS components. In a variety of cases, the manager of the deployment environment (I'll call them the "deployer" below) may wish to disable some of these DS components.I'm aware of three ways to do this, all of which are problematic for one reason or another.* Use the require configuration policy-- If the component developer requires a configuration policy, then in theory the deployer could disable a component by deleting the corresponding configuration. The problem here is that we don't want a deployer to delete one of our standard configurations. Should they want to reenable the component in the future, they would have to have a backup of the configuration something which seems error prone. It is also likely (and this may be specific to our application) that when a new version is deployed, a new configuration would be deployed and the component would be reenabled.* Use the SCR API to disable the component-- This almost works :) It, however, isn't declarative -- you have to write code which uses this API. And it is a bit tricky because disabling a component isn't stateful, i.e. restarting the SCR implementation bundle will automatically restart any manually disabled components.* Implement a custom component.enabled configuration property and read it in the activate method.-- This actually works perfectly but is non-standard and requires that every component developer explicitly support this. And it is also fundamentally wrong -- what we want is to disable the component. If you use this technique the component is actually activated, it just isn't functional. Which means that referring components still get the "disabled" component.I'm curious if others have similar requirements, if there are options I haven't considered, and whether or not the OSGi EG has any plans to provide native support for declarative disabling of components.Best regards,Justin Edelson_______________________________________________
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
