Difference between revisions of "Embedding OSGi"

From Protege Wiki

Jump to: navigation, search
(Created page with '==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 p...')
 
(Embedding OSGi inside a host application: (checkpoint save))
Line 2: Line 2:
  
 
There are many reasons to embed 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).
+
* 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.
This application finds and initializes a plugin  (PluginImpl.java).  I
+
* you have an existing OSGi implementation (e.g. Protege 4) which you want to run in a non-OSGi application setting.
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
+
There are several examples of OSGi showing up on the web.  In particular, the Apache
(conflict.jar) used by the host application.  The plugin for the hsot
+
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 checked out  and run by executing ''ant run''.
application needs to use the same routines from the library but needs
+
 
to use a different version of the library (conflict-v2.jar).
+
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 starts up OSGi and the work of the plugin is then done in the OSGi environment.
 +
 
 +
There are two
 +
 
 +
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).

Revision as of 13:09, 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 following demonstration of how a plugin for a host application can be implemented inside a embedded OSGi environment. The demonstration can be checked out and 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 starts up OSGi and the work of the plugin is then done in the OSGi environment.

There are two

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).

Personal tools