I am new to OSGi and came across several examples about OSGi services.
For example:
import org.osgi.framework.*;
import org.osgi.service.log.*;
public class MyActivator implements BundleActivator {
public void start(BundleContext context) throws Exception {
ServiceReference logRef =
context.getServiceReference(LogService.class.getName());
}
}
My question is, why do you use
getServiceReference(LogService.class.getName())
instead of
getServiceReference("LogService")
If you use LogService.class.getName() you have to import the Interface. This also means that you have to import the package org.osgi.services.log in your MANIFEST.MF.
Isn’t that completely counterproductive if you want to reduce dependencies to push loose coupling? As far as I know one advantage of services is that the service consumer doesn’t have to know the service publisher. But if you have to import one specific Interface you clearly have to know who’s providing it. By only using a string like “LogService” you would not have to know that the Interface is provided by org.osgi.services.log.LogService.
What am I missing here?
Looks like you’ve confused implementation and interface
Using the actual interface for the name (and importing the interface , which you’ll end up doing anyway) reenforces the interface contract that services are designed around. You don’t care about the implemenation of a LogService but you do care about the interface. Every LogService will need to implement the same interface, hence your use of the interface to get the service. For all you know the LogService is really a wrapper around SLF4J provided by some other bundle. All you see is the interface. That’s the loose coupling you’re looking for. You don’t have to ship the interface with every implementation. Leave the interface it’s own bundle and have multiple implementations of that interface.
Side note: ServiceTracker is usually easier to use, give it a try!
Added benefits: Using the interface get the class name avoids spelling mistakes, excessive string literals, and makes refactoring much easier.
After you’ve gotten the ServiceReference, your next couple lines will likely involve this: