Studying services - OSGi in Action - page 143

public void log(ServiceReference sr, int level, String message) {}
public void log(ServiceReference sr, int level, String message,
Throwable exception) {}
};
}

public void modifiedService(ServiceReference ref, Object service) {}

public void removedService(ServiceReference ref, Object service) {}
}
All you have to do to decorate the Log Service is pass the customizer to the tracker:

m_logTracker = new ServiceTracker(context, LogService.class.getName(),
new LogServiceDecorator());
Now any Log Service returned by this tracker will add angle brackets to the logged
message. This is a trivial example, but we hope you can see how powerful customizers
can be. Service tracker customizers are especially useful in separating code from OSG i-
specific interfaces, because they act as a bridge connecting your application code to
the service registry.
You've seen three different ways to access OSG i services: directly through the bun-
dle context, reactively with service listeners, and indirectly using a service tracker.
Which way should you choose? If you only need to use a service intermittently and
don't mind using the raw OSG i API , using the bundle context is probably the best
option. At the other end of the spectrum, if you need full control over service dynam-
ics and don't mind the potential complexity, a service listener is best. In all other situ-
ations, you should use a service tracker, because it helps you handle the dynamics of
OSG i services with the least amount of effort.

What? No abstractions?
If none of these options suit you, and you prefer to use a higher-level abstraction,
such as components, this is fine too. As we mentioned at the start of this chapter,
it's possible to build component models on top of these core APIs. This is exactly
what many people have been doing for the past few years, and several service-oriented
component frameworks are based on OSGi; we'll discuss them in chapters 11 and 12.
But remember, all these component frameworks make subtle but important semantic
choices when mapping components to the OSGi service model. If you need to cut through
these abstractions and get to the real deal, now you know how.

Now that you know all about OSG i services and their dynamics, let's look again at the
paint program and see where it may make sense to use services.

4.4 Using services in the paint example

You last saw the paint example back in section 3.4, where you used an extender pat-
tern to collect shapes. Why don't you try using a service instead? A shape service
makes a lot of sense, because you can clearly define what responsibilities belong to a