OSGi revealed - OSGi in Action - page 14

To see this example in action, go in the chapter01/greeting-example/modularity/
directory in the topic's companion code, and type ant to build it and java -jar
main.jar to run it. Although the example is simple, it illustrates that creating OSG i
bundles out of existing JAR files is a reasonably non-intrusive process. In addition, there
are tools that can help you create your bundle metadata, which we'll discuss in appendix
A; but in reality, no special tools are required to create a bundle other than what
you normally use to create a JAR file. Chapter 2 will go into all the juicy details of
OSG imodularity.

1.3.2 Lifecycle layer example

In the last subsection, you saw that it's possible to take advantage of OSG i functionality
in a non-invasive way by adding metadata to your existing JAR files. Such a simple
approach is sufficient for most reusable libraries, but sometimes you need or want to
go further to meet specific requirements or to use additional OSG i features. The life-
cycle layer moves you deeper into the OSG i world.
Perhaps you want to create a module that performs some initialization task, such
as starting a background thread or initializing a driver; the lifecycle layer makes this
possible. Bundles may declare a given class as an activator , which is the bundle's hook
into its own lifecycle management. We'll discuss the full lifecycle of a bundle in chap-
ter 3, but first let's look at a simple example to give you an idea of what we're talking
about. The following listing extends the previous Greeting class to provide a single-
ton instance.

Listing 1.3 Extended greeting implementation

package org.foo.hello;

public class Greeting {
static Greeting instance;
final String m_name;

Greeting(String name) {
m_name = name;
}

Clients must
use singleton

public static Greeting get() {
return instance;
}

public void sayHello() {
System.out.println("Hello, " + m_name + "!");
}
}
Listing 1.4 implements a bundle activator to initialize the Greeting class singleton
when the bundle is started and clear it when it's stopped. The client can now use the
preconfigured singleton instead of creating its own instance.