won't be satisfied until there's a configuration for it in Configuration Admin. The
require policy is useful in cases where no sensible default value can be given for a
configuration property (such as a database URL ). The ignore policy indicates that
only the declared component properties should be considered.
You specify configuration policies like this:
<component name="org.foo.example" configuration-policy="require">
In this example, the component requires a corresponding configuration to be present
in Configuration Admin, or else it can't be satisfied.
Configuration Admin Service factories
In chapter 9, you saw that it's possible to use the Configuration Admin Service with
one of two types of managed services, either a ManagedService or a Managed-
ServiceFactory . The first takes a single configuration and uses it to configure a ser-
vice provided by a bundle; the second allows multiple configurations to be created—
each corresponding to a new service.
This pattern can be applied to Declarative Services components. If the component
name matches a registered PID for a nonfactory configuration, the Declarative Services
framework creates a single instance of the component. But if the component name
matches a registered factory PID, a new component instance is created for each con-
figuration associated with the factory PID. This provides a lightweight way of construct-
ing several different component instances from a common component definition.
Components can be satisfied by the availability of their service dependencies and con-
figuration, but the Declarative Services framework still won't activate (instantiate) a
component until another bundle requests its provided service. What about a compo-
nent that doesn't provide a service? How will it ever be activated?
IMMEDIATE VS. DELAYED COMPONENTS
Many components, such as the shape components in the paint example, exist solely to
provide a function to other parts of an application. If no other deployed bundles con-
sume the services these bundles provide, there's no need to expend resources activat-
ing the associated components. Components that provide services are delayed by
default in Declarative Services. Sometimes this delayed behavior is problematic. If you
look again at the component declaration of the paint frame, you see that it specifies
the immediate="true" attribute:
This turns off the delayed behavior and forces the Declarative Services implementa-
tion to construct the paint frame as soon as it's satisfied. Because the paint frame com-
ponent provides a service, it would be delayed by default. You need it to be immediate