Java Reference
In-Depth Information
In the previous chapter, you used a
BundleTracker
to react as shape bundles came
and went. This proved to be a good design choice, because it meant the
ShapeTracker
class could process shape events and trigger the necessary Swing actions. All you need
to change is the source of shape events, as shown in the following listing; they now
come from the
ServiceTracker
methods.
Listing 4.16 Sending shape events from
ServiceTracker
methods
public Object addingService(ServiceReference ref) {
SimpleShape shape = new DefaultShape(m_context, ref);
processShapeOnEventThread(ADDED, ref, shape);
return shape;
}
public void modifiedService(ServiceReference ref, Object svc) {
processShapeOnEventThread(MODIFIED, ref, (SimpleShape) svc);
}
public void removedService(ServiceReference ref, Object svc) {
processShapeOnEventThread(REMOVED, ref, (SimpleShape) svc);
((DefaultShape) svc).dispose();
}
Ungets service
and clears fields
The processing code also needs to use service properties rather than extension
metadata:
String name = (String) ref.getProperty(SimpleShape.NAME_PROPERTY);
Icon icon = (Icon) ref.getProperty(SimpleShape.ICON_PROPERTY);
And that's all there is to it. You now have a service-based paint example. To see it in
action, go into the chapter04/paint-example/ directory of the companion code, type
ant
to build it, and type
java
-jar
launcher.jar bundles
to run it. The fact that you
needed to change only a few files is a testament to the non-intrusiveness of
OSG
i ser-
vices if you already use an interface-based approach.
We hope you can also see how easy it would be to do this in reverse and adapt a ser-
vice-based example to use extensions. Imagine being able to decide when and where
to use services in your application, without having to factor them into the initial
design. The
OSG
i service layer gives you that ability, and the previous layers help you
manage and control it. But how can the module and lifecycle layers help; how do they
relate to the service layer?
4.5
Relating services to modularity and lifecycle
The service layer builds on top of the module and lifecycle layers. You've already seen
one example, where the framework automatically unregisters services when their reg-
istering bundle stops. But the layers interact in other ways, such as providing bundle-
specific (also known as
factory
) services and specifying when you should unget and
unregister services, and how you should bundle up services. But let's start with how
modularity affects what services you can see.
