OSGi and Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 430

As you can see, the code is simple, and in point of fact does nothing to betray the fact that we're
going to deploy it on top of OSGi. The next class, called an Activator, is required for every bundle. The
Activator registers services and receives a life-cycle hook to set the stage for the service. Similarly, it
reacts to events and register listeners.
package com.apress.springenterpriserecipes.osgi.helloworld.service;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import java.util.Properties;
public class Activator implements BundleActivator {
public void start(BundleContext bundleContext) throws Exception {
System.out.println("Start: ");
bundleContext.registerService(
GreeterService.class.getName(),
new GreeterServiceImpl(),
new Properties());
}
public void stop(BundleContext bundleContext) throws Exception {
System.out.println("Stop: "); // NOOP
}
}
The Activator implements BundleActivator , which has a few life-cycle callback methods. We avail
ourselves of the start method when the jar is installed to register the service that's contained. We could
register many services. The first parameter, a String, is the service name, sort of like a JNDI name or a
Spring beanName. The second parameter is the implementation of the service. The third parameter—
the java.util.Properties object being passed to the registerService —are key/value pairs, called
service attributes. The client can use them as a predicate to qualify what service should be returned
when looking the service up in the registry. Here, we specify nothing.
This is all the Java code for this service, but we do need to expand on the MANIFEST itself a little bit,
to specify extra metadata that OSGi uses in deploying the service. How you do this is entirely at your
discretion, and it's simple enough that you could get away with doing it by hand. We use a Maven
plug-in that handles the minutiae for us, though there are other approaches as well. Remember, OSGi
bundles are simply standard .jar files with customized MANIFESTs that OSGi consumes at runtime.