where we would specify any values to narrow the criteria for the search for a service. Because there's
only one that could possibly match in this case, we won't specify anything. Note that there is no
guarantee you'll get a reference to the service, or that you'll get only one. Indeed, you may be given any
number of ServiceReference s, which is why the return type is scalar. This is a very different paradigm
than more traditional component models such as EJB, which treat the inability to return a handle to a
service as an error. This is also somewhat counter-intuitive from how traditional service registries (such
as JNDI) work. When we're sure we have a handle to a service, we redeem it for an interface to the actual
service itself, somewhat like an EJBHome , using the bundleContext.getService(ServiceReference)
method. You can see, already, where Spring might be able to lend a hand—in this resource lookup and
Let's examine the final MANIFEST for the client. It's not much different from what we've done
before. It differs mainly in that it lists our service as a dependency. Apart from that, it's pretty boilerplate.
The Activator is the only thing that's changed from the previous example. If you're following with
Maven, don't forget to specify the changed Activator class in the plug-in. Additionally, we're using the
interface from the service jar we produced in the last example. The Maven plug-in automatically adds
this to your Import-Package MANIFEST header.
Created-By: Apache Maven Bundle Plugin
Nothing too exceptional here, except the aforementioned Import-Package . Install the bundle as we
did for the service. When the bundle begins to load, and start, it calls the start method of the Activator.
You should see greetings being enumerated on the console. You've successfully completed your first