Component models and frameworks - OSGi in Action - page 364

if (log != null) {
log.log(level,msg);
}
}
}
Here, you use a java.util.concurrent.AtomicReference object to hold the Log-
Service , which you set in the binding methods. You use an AtomicReference to pro-
tect yourself from threading issues related to the service being bound or unbound
while your component is using it. You also need to be aware of the fact that the Log-
Service may in fact not be bound because it's optional, so you check whether the ser-
vice is bound and log a message if so. The use of a wrapper method to achieve this is
one possible mechanism; for a more advanced solution, you could use null objects to
protect other areas of code from this execution-time issue.
So far, you've seen how to describe components that publish and consume ser-
vices, but we've only indirectly discussed component lifecycle management. Next,
we'll provide more details about the lifecycle of Declarative Services components.

11.3.4 Declarative Services component lifecycle

Having described your components, the next issue to consider is their lifecycle. When
are components created? When are they destroyed? Are there any callbacks at these
stages? How can you access the BundleContext if there is no BundleActivator ? We'll
deal with each of these questions in this section.

COMPONENT LIFECYCLE STAGES
In chapter 3, we introduced the bundle lifecycle: in essence, bundles are installed,
then resolved, and then activated. Declarative Services defines a similar lifecycle for
components, where they're enabled, then satisfied, and then activated. The Declara-
tive Services specification defines the following stages to a component lifecycle:

Enabled —A simple Boolean flag controls whether the component is eligible for
management.

■

Satisfied —The component is enabled, its mandatory dependencies are satisfied,
any provided services are published in the service registry, but the component
itself isn't yet instantiated.

■

Activated —The component is enabled, its mandatory dependencies are satis-
fied, any provided services are published in the service registry, and the compo-
nent instance has been created as a result of a request to use its service.

■

Modified —The configuration associated with the component has changed, and
the component instance should be notified.

■

Deactivated —Either the component has been disabled or its mandatory depen-
dencies are no longer satisfied, so its provided services are no longer available
and its component instance, if created, is dereferenced for garbage collection.

■

You can enable/disable a component declaratively using the enabled attribute of the
<component> XML element and programmatically using the ComponentContext