Studying services - OSGi in Action - page 147

4.5.1 Why can't I see my service?

Sometimes you may ask yourself this question and wonder why, even though the OSG i
framework shows a particular service as registered, you can't access it from your bun-
dle. The answer comes back to modularity. Because multiple versions of service inter-
face packages may be installed at any given time, the OSG i framework only shows your
bundle services using the same version. The reasoning behind this is that you should
be able to cast service instances to any of their registered interfaces without causing
a ClassCastException .
But what if you want to query all services, regardless of what interfaces you can see?
Although this approach isn't common, it's useful in management scenarios where you
want to track third-party services even if they aren't compatible with your bundle. To
support this, the OSG i framework provides a so-called All* variant of the getService-
References() method to return all matching services, regardless of whether their
interfaces are visible to the calling bundle. For example:

ServiceReference[] references =
bundleContext.getAllServiceReferences(null, null);
This returns references to all services currently registered in the OSG i service registry.
Similarly, for service listeners there's an All* extension of the ServiceListener inter-
face, which lets you receive all matching service events. The ServiceTracker is
the odd one out, with no All* variant—to ignore visibility, you start the tracker
with open(true) .
You've seen that although one bundle can see a service, another bundle with dif-
ferent imports may not. How about two bundles with the same imports? They see the
same service instances. What if you want them to see different instances—is it possible
to customize services for each consumer?

4.5.2 Can I provide a bundle-specific service?

You may have noticed that throughout this chapter, you've assumed that service
instances are created first and then published, discovered, and finally used. Or, to put
it another way, creation of service instances isn't related to their use. But sometimes
you want to create services lazily or customize a service specifically for each bundle
using it. An example is the simple Log Service implementation from section 4.3. None
of the Log Service methods accept a bundle or bundle context, but you may want to
record details of the bundle logging the message. How is this possible in OSG i?
Doesn't the registerService() method expect a fully constructed service instance?
The OSG i framework defines a special interface to use when registering a service.
The ServiceFactory interface acts as a marker telling the OSG i framework to treat
the provided instance not as a service, but as a factory that can create service instances
on demand. The OSG i service registry uses this factory to create instances just before
they're needed, when the consumer first attempts to use the service. A factory can
potentially create a number of instances at the same time, so it must be thread safe: