Java Reference
In-Depth Information
bundle, you need to stop it using a different thread. For this reason, you create and
start a new thread of type
SelfStopThread
, which executes the
Bundle.stop()
method
C
. There's one final point to note in this example: you change the behavior
of stopping a bundle in this case from synchronous to asynchronous. Ultimately, this
shouldn't matter much, because the bundle will be stopped anyway.
You should also modify the implementation of the
update
and
uninstall
com-
mands the same way. Using the shell to stop the framework (the system bundle) also
requires special consideration. Why? Because stopping the system bundle causes the
framework to stop, which stops every other bundle. This means you'll stop your bun-
dle indirectly, so you should make sure you're using a new thread.
We hope you now have a good understanding of what is possible with
OSG
i's lifecy-
cle layer. Next, you'll apply this knowledge to the paint program.
3.4
Dynamically extending the paint program
Let's look at how you can use the individual parts of the lifecycle layer to dynamically
extend the paint program. As you'll recall from the last chapter, you first converted a
nonmodular version of the paint program into a modular one using an interface-
based programming approach for the architecture. This is great because you can
reuse the resulting bundles with minimal extra work. The bundles containing the
shape implementations don't need to change, except for some additional metadata in
their manifest. You just need to modify the paint program to make it possible for
shapes to be added and removed at execution time.
The approach you'll take is a well-known pattern in the
OSG
i world, called the
extender pattern
. The main idea behind the extender pattern is to model dynamic exten-
sibility on the lifecycle events (installing, resolving, starting, stopping, and so on) of
other bundles. Typically, some bundle in the application acts as the
extender
: it listens
for bundles being started and/or stopped. When a bundle is started, the extender
probes it to see if it's an
extension
bundle. The extender looks in the bundle's manifest
(using
Bundle.getHeaders()
) or the bundle's content (using
Bundle.getEntry()
)
for specific metadata it recognizes. If the bundle does contain an extension, the exten-
sion is described by the metadata. The extender reads the metadata and performs the
necessary tasks on behalf of the extension bundle to integrate it into the application.
The extender also listens for extension bundles to be stopped, in which case it removes
the associated extensions from the application.
That's the general description of the extender pattern, which is shown in figure 3.16.
Let's look at how you'll use it in the paint program.
You'll treat the shape implementations as extensions. The extension metadata will
be contained in the bundle manifest and will describe which class implements the
shape contained in the shape bundle. The extender will use this information to load
the shape class from the bundle, instantiate it, and inject it into the application when
an extension bundle is activated. If a shape bundle is stopped, the extender will
remove it from the application. Figure 3.17 illustrates this usage scenario.
