Studying services - OSGi in Action - page 132

What's the best way to cope with potential dynamism? How can you get the most
from dynamic services without continual checking and rechecking? The next section
discusses potential pitfalls and recommended approaches when you're programming
with dynamic services.

4.3 Dealing with dynamics

In the last section, we covered the basics of OSG i services, and you saw how easy it is to
publish and discover services. In this section, we'll look more closely at the dynamics
of services and techniques to help you write robust OSG i applications. To demon-
strate, you'll use the OSG i Log Service.
The Log Service is a standard OSG i service, one of the so-called compendium or non-
core services. Compendium services will be covered more in section 4.6.2. For now, all
you need to know is that the Log Service provides a simple logging facade, with vari-
ous flavors of methods accepting a logging level and a message, as shown in the follow-
ing listing.

Listing 4.2 OSGi Log Service

package org.osgi.service.log;
import org.osgi.framework.ServiceReference;
public interface LogService {
public static final int LOG_ERROR = 1;
public static final int LOG_WARNING = 2;
public static final int LOG_INFO = 3;
public static final int LOG_DEBUG = 4;
public void log(int level, String message);
public void log(int level, String message,
Throwable exception);
public void log(ServiceReference sr, int level, String message);
public void log(ServiceReference sr, int level, String message,
Throwable exception);
}
With OSG i, you can use any number of possible Log Service implementations in the
example, such as those written by OSG i framework vendors or others written by third-
party bundle vendors. To keep things simple and to help you trace what's happening
inside the framework, you'll use your own dummy Log Service that implements only
one method and outputs a variety of debug information about the bundles using it.

NOTE The examples in the next section are intended purely to demonstrate
the proper usage of dynamic OSG i services. To keep these explanatory code
snippets focused and to the point, they occasionally avoid using proper pro-
gramming techniques such as encapsulation. You should be able to join the
dots between the patterns we show you in these examples and real-world OO
design. If you aren't interested in the gory details of the OSG i service API and
just want a simple, safe way to get services, skip ahead to the tracker example
(section 4.3.3) or look at the component models in chapters 11 and 12.