Leveraging OSGi to address Eclipse plug-in challenges

Use the Open Services Gateway initiative API to eliminate Eclipse plug-in dependencies

This article describes a plug-in example that uses XML to register extensions for well-defined extension points. By enabling Plug-ins to perceive extention Registry and provide OSGi services, we can complete this complete component decoupling operation.

Plug-ins, extension points, OSGi

As you know, Eclipse's component architecture is plug-in-which means that a set of code components into a single component and then registered as one of its components with the Eclipse framework, and other components can bind to or invoke the component. An extension point is a way for plug-ins to allow other plug-ins to provide additional functionality to a plug-in that exposes an extension point. Now take advantage of all these plug-ins and wrap them to the managed runtime, where the plug-in can move in and out, and you can get OSGi (basically).

Sample Plug-ins

Let's start with a basic plug-in that exposes the extension point so that you can register a new string map for the synonym service. This service allows other services to register a word and map it to another word (synonym). The basic extensions contain very simple elements: one word and, of course, a new synonym. The basic structure of this plug-in extension point is shown in table 1.

Table 1. Elements of the sample plug-in

Plug-in name	Com.company.SynonymRegistry
Extension points	Synonyms
Elements	Word--the word you want to add a synonym to Synonyms--synonyms you want to register

We also want to register the plug-in as an OSGi service. This means that it is loaded only when explicitly performing this operation and will be available for other clients to use declaratively. To use this service, other customers only need to know the Interface and OSGi class names. In our example, we do not actually invoke the service because the extension point is assumed. We will use the OSGi API to tell us when this service is in and out, so we can register the extension points correctly.

Now this is just an example, and using an extension point for this concept may not be the best approach. The purpose of this basic example is to dynamically register a new extension, along with plug-in lifecycle events using the OSGi API.

Mediator Plugin

The next plug-in is a Third-party plug-in that understands known services and extension points but does not want to bind to this plug-in because it will rely on the plug-in for Run-time resolution later. This means that the plug-in can reside on a machine that may not exist in the referenced plug-in (com.company.SynonymRegistry). Because we now live in OSGi and the dynamic runtime world, we want to make sure that the plug-in runs without causing a run-time failure or error. Our mediator plug-in will accept the synonym XML file and register each synonym with the Synonymregistry plug-in by using the provided extension points.

Listing 1. Sample XML file for concept validation

Synonyms.xml
<?xml version= "1.0" encoding= "UTF-8"?>
<synonyms>
<entry word= "mediator" synonym= "broker"/> <entry word= Mediator synonym= "Go-Between"/> <entry word= "mediator"
synonym= "Interceder"/>
<entry word= "mediator" synonym= "intermediary"/>
<synonyms>

The first thing the mediator plug-in does in its start () method is to register with the OSGi service as a service initialization listener. We want to invoke the OSGi service method Addservicelistener () on the Bundlecontext object passing in the start () method. The following code shows an example of invoking this API through incoming code and the service ID we are interested in.

Context.addservicelistener (This, "com.company.SynonymRegistry");

By providing a filter, you can tell the OSGi service registry just to notify you of the status changes in the specified service. In this case, the filter is just the class name of the Synonymregistry class.

You may be inquisitive. The answer is in the startup sequence. In the area of OSGi, we don't always know when another service is available, so we need to explain that. By registering as a service listener, we can learn when the service starts and stops. If the service is unavailable, allow us to cache synonyms. When the service is actually available, we are notified and registered for expansion.