on Jun 20th, 2011Using OSGi services to single-source an RCP and RAP Application
Probably one of RAP’s best known features is its single-sourcing capabilities. Some time ago we created a guide on Single-Sourcing RCP and RAP applications. The guide recommended a technique where a facade and fragments were used to invoke the RCP or RAP implementation during runtime. With this post I want to show you how to achieve the same the OSGi way.
For single-sourcing a RAP or RCP application, its straightforward to use the power of OSGi because it’s included in both platforms out-of-the-box. OSGi has a central concept called services which are simply POJOs and are used to allow communication between modules. And, you can register or resolve services at any time in your code.
The basic Idea behind using OSGi services for single-sourcing is as follows. We need to extract all the things that vary into separate, platform specific bundles. To use the different implementations, we have to create an interface in a “common” bundle that contains the methods we want to use. The platform specific bundles have to register an implementation of this interface as a service. In the “common” bundle we can reference the registered services and use them to get the platform specific stuff. More specifically, we register a RAP implementation in a “rap” bundle and an RCP implementation in an “rcp” bundle. The only thing we need to do then is to start the right bundles on the associated platform to get the right service.
With this solution we can extract the platform specific stuff into separate bundles and we don’t have to rely on fragments. So enough talking. Let’s look at some code. I decided to create a very simple single-sourcing interface which can be used to get the WidgetUtil.CUSTOM_VARIANT constant value. This constant exists only in RAP so, it’s a good example for showing how to handle the differences.
public interface ISingleSourcingService { String getCustomVariantString(); }
I have created three bundles: one that contains the application which is entitled “com.eclipsesource.app” and one for each platform. These are called “com.eclipsesource.app.rap” and “com.eclipsesource.app.rcp”. Both platform bundles implement the interface.
RAP:
@Override public String getCustomVariantString() { return WidgetUtil.CUSTOM_VARIANT; }
RCP:
@Override public String getCustomVariantString() { // There are no custom variants in RCP return ""; }
And both bundles are registering the service in their Activator during the start method call.
public void start( BundleContext bundleContext ) throws Exception { Activator.context = bundleContext; registration = context.registerService( ISingleSourcingService.class.getName(), new RAPSingelSourcingService(), null); }
When it comes to using the service in the common “app” bundle we can use a ServiceTracker to get the service implementation (you can also use DS).
private ISingleSourcingService getSingleSourcingService() { // We use a tracker to get the service. We also can use DS to get it. Bundle bundle = FrameworkUtil.getBundle( getClass() ); BundleContext context = bundle.getBundleContext(); ServiceTracker tracker = new ServiceTracker( context, ISingleSourcingService.class.getName(), null ); tracker.open(); ISingleSourcingService service = tracker.getService(); tracker.close(); return service; }
The only thing we have to do now is to create two launch configurations which contain the associated platform-specific bundle.
That’s it! You can find the sources in this github repository. Have fun using OSGi services to single-source applications.
. This can’t happen with McGeary’s plug-in.
). The bundle contributes the functionality to automatically terminate a running OSGi Instance when you try to launch the same instance a second time. This functionality already existed in the RAP launcher created by 
