You can not easily disable components.
You can do it the other way round though by using the
configurationPolicy REQUIRE. If you specify that the component needs a
mandatory config then it will only be enabled if the config exists.
So the deployer can use the existence of configs to enable / disable
modules even at runtime.
Christian
On 11.02.2016 18:52, Justin Edelson wrote:
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
--
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
