Difference between revisions of "Embedding OSGi"

Revision as of 12:05, August 7, 2009

Embedding OSGi inside a host application

There are many reasons to embed OSGi inside a host application:

• the host application may have an extension mechanism that offers

plugins no classloader protection from other extensions. This means that version problems can crop up between different extensions.

• you have an existing OSGi implementation (e.g. Protege 4) which you

want to run in a non-OSGi application setting. There are several examples of OSGi showing up on the web. In particular, the Apache and Equinox groups have teamed up to devise a scheme that works with tomcat. Inside the OSGi environment, bundles see the standard OSGi servlet services which are transparently mapped to the underlying tomcat implementation. In response to a potential Protege developer who was having serious classloader problems I implemented the [http://smi-protege/repos/protege/protege4/misc/example.embedded/trunk following demonstration] of how a plugin for a host application can be implemented inside a embedded OSGi environment. The demonstration can be run by executing ant run.

In the HostApplication project, I simulated the host application (Host.java). This application finds and initializes a plugin (PluginImpl.java). I did not simulate the plugin mechanism inside the host application; the call to initialize the plugin is a simple call to a member of the PluginImpl class. The PluginImpl class then immediately stargs up OSGi and the work is then

My example included a class loader conflict. There is a library (conflict.jar) used by the host application. The plugin for the hsot application needs to use the same routines from the library but needs to use a different version of the library (conflict-v2.jar).