Java Reference
In-Depth Information
For the standalone paint program, you don't need to change the shape bundles. What
does need to be changed? The original service-based paint program didn't need a
launcher, because the bundle activator in the paint bundle served this purpose. For
the standalone paint program, you need a launcher that creates the paint frame and
the framework instances and wires everything together. Additionally, because the
paint program needs a common class definition to interact with bundles implement-
ing shapes, you must move the shape
API
into the standalone application so the appli-
cation and bundles can use the same
SimpleShape
service-interface definition. Note
that figure 13.4 depicts the application as a quasi bundle with an exported package
and service dependencies. This is just for illustrative purposes: the application is a nor-
mal
JAR
file. The structure of the modified paint program source code is as follows:
org/foo/paint/
DefaultShape.java
Main.java
PaintFrame.java
ShapeTracker.java
ShapeComponent.java
underc.png
org/foo/shape
SimpleShape.java
What's the design of the standalone paint program? Recall the original design of the
paint program: the main paint frame was designed in such a way as to be injected with
shape implementations. This approach had the benefit of allowing you to limit depen-
dencies on
OSG
i
API
and to concentrate your
OSG
i-aware code in the shape tracker. In
keeping with these design principles, you'll do most of the work in the launcher
Main
class, which creates the embedded framework instance, deploys the shape bundles,
creates the paint frame, and binds the paint frame to the embedded shape services.
Perhaps at this point you're thinking that this sounds similar to the generic frame-
work launcher you created in the previous section. You're correct. Using the framework
in an embedded way isn't all that different, other than the issues we outlined previously.
As a result, the launcher code for the standalone paint program will bear a striking
resemblance to the generic launcher. The different aspects it illustrates are as follows:
Sharing code from the class path to bundles
■
Using services on the outside
■
Providing services to the inside
■
This last aspect doesn't have an analogue in the original service-based paint program,
but we include it to demonstrate that it's possible to provide services from the outside.
As before, we'll break the launcher into small snippets and describe each one. Let's
get started.
PERFORMING THE MAIN TASKS
Because the paint program is no longer a bundle, you replace its bundle activator with
a
Main
class. The primary tasks this class performs are easy to discern from the
main()
method.
