Component models and frameworks - OSGi in Action - page 365

interface, which you'll see shortly. A simple use case for this is to reduce startup time
by disabling all but a small number of components and then enabling additional
components later as needed. Similarly, neither the enabled nor satisfied stages result
in instantiating the component class in an effort to avoid unnecessary work.
When a component is enabled, it may become satisfied. A component can become
satisfied only if all of its mandatory dependencies are satisfied. After it's satisfied, it
may become activated if its provided service is requested. Activation results in the
component being instantiated. Each component description ultimately is reified as a
single component instance that will be managed by the Declarative Services frame-
work; by default, a one-to-one mapping exists between a component description and a
component instance.
The component lifecycle is coupled to the lifecycle of its containing bundle. Only
components in activated bundles are eligible for lifecycle management. If a bundle is
stopped, the Declarative Services framework automatically deactivates all activated
components contained in it.
Let's dive into some code to see what this means in practice for the paint applica-
tion. First, let's look at the PaintFrame class.
Listing 11.6 Lifecycle-related code from Declarative Services PaintFrame class
public PaintFrame() {
super("PaintFrame");
...
}
...
void activate(Map properties) {
Integer w = (Integer) properties.get(".width");
Integer h = (Integer) properties.get(".height");
int width = w == null ? 400 : w;
int height = h == null ? 400 : h;
setSize(width, height);
SwingUtils.invokeAndWait(new Runnable() {
public void run() {
setVisible(true);
}
});
}
void deactivate() {
SwingUtils.invokeLater(new Runnable() {
public void run() {
setVisible(false);
dispose();
}
});
}
...
}