Embedding OSGi - Revision history

Tredmond at 21:09, February 16, 2010

2010-02-16T21:09:33Z

Tredmond: /* Embedding OSGi inside a host application */

2010-02-16T21:08:17Z

‎Embedding OSGi inside a host application

Tredmond: /* Embedding OSGi inside a host application */

2010-02-16T21:06:02Z

‎Embedding OSGi inside a host application

Tredmond: /* Removing the Import Version Constraint */

2009-08-23T23:41:16Z

‎Removing the Import Version Constraint

Tredmond: /* Altering the imported version of the library */

2009-08-23T23:40:52Z

‎Altering the imported version of the library

Tredmond: /* Embedding OSGi inside a host application */

2009-08-23T23:37:22Z

‎Embedding OSGi inside a host application

Tredmond: /* Embedding OSGi inside a host application */

2009-08-23T22:49:39Z

‎Embedding OSGi inside a host application

Tredmond: /* Altering the imported version of the library */

2009-08-09T00:34:59Z

‎Altering the imported version of the library

Tredmond: /* Embedding OSGi inside a host application */

2009-08-09T00:32:51Z

‎Embedding OSGi inside a host application

Tredmond: /* Embedding OSGi inside a host application */

2009-08-09T00:16:51Z

‎Embedding OSGi inside a host application

@@ Line 87: / Line 87: @@
 Import-Package: org.example.conflict;version="2.0.0",
 </pre>
-in the plugin bundle [http://smi-protege.stanford.edu/repos/protege/protege4/misc/example.embedded/trunk/PluginBundle/META-INF/MANIFEST.MF manifest] as follows
+in the plugin bundle [http://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/embedded/trunk/PluginBundle/META-INF/MANIFEST.MF manifest] as follows
 <pre>
 Import-Package: org.example.conflict,
@@ Line 103: / Line 103: @@
 Import-Package: org.example.conflict;version="2.0.0",
 </pre>
-in the plugin bundle [http://smi-protege.stanford.edu/repos/protege/protege4/misc/example.embedded/trunk/PluginBundle/META-INF/MANIFEST.MF manifest] as follows
+in the plugin bundle [http://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/embedded/trunk/PluginBundle/META-INF/MANIFEST.MF manifest] as follows
 <pre>
 Import-Package: org.example.conflict;version="[1.0.0,2.0.0)",
@@ Line 127: / Line 127: @@
 === Removing the host application library fron OSGi ===
-Now, in addition to making the change described above to the version of the conflict library imported by the plugin bundle, suppose that we also change the OSGi [http://smi-protege.stanford.edu/repos/protege/protege4/misc/example.embedded/trunk/staged/osgi/configuration/config.ini configuration file] to not pass the conflicting package to the OSGi environment.  This is the very last part of the
+Now, in addition to making the change described above to the version of the conflict library imported by the plugin bundle, suppose that we also change the OSGi [http://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/embedded/trunk/staged/osgi/configuration/config.ini configuration file] to not pass the conflicting package to the OSGi environment.  This is the very last part of the
 <pre>
      org.osgi.framework.system.packages

@@ Line 25: / Line 25: @@
       org.osgi.framework.system.packages
 </pre>
-If you examine this declaration in [http://smi-protege.stanford.edu/repos/protege/protege4/misc/example.embedded/trunk/staged/osgi/configuration/config.ini the OSGi configuration file] (look at the end of the fourth line) you will see that the conflicting library is explicitly included:
+If you examine this declaration in [http://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/embedded/trunk/staged/osgi/configuration/config.ini the OSGi configuration file] (look at the end of the fourth line) you will see that the conflicting library is explicitly included:
 <pre>
     org.osgi.framework.system.packages=...,org.example.conflict;version="1.0.0"
@@ Line 31: / Line 31: @@
 Note the version information, this will be important later.  If this entry is removed then OSGi environment will not  be able to load this class from the host application class loaders.  This method is probably the simplest approach for most people.
-Second, bundles in the OSGi framework can control where and how they load their classes.  For example , [http://smi-protege.stanford.edu/repos/protege/protege4/misc/example.embedded/trunk/PluginBundle/META-INF/MANIFEST.MF the manifest] of one of the bundles running in the OSGi environment explicitly imports the library definitions in conflict.  Note the first line from that manifest below:
+Second, bundles in the OSGi framework can control where and how they load their classes.  For example , [http://smi-protege.stanford.edu/repos/protege/protege4/misc/examples/embedded/trunk/PluginBundle/META-INF/MANIFEST.MF the manifest] of one of the bundles running in the OSGi environment explicitly imports the library definitions in conflict.  Note the first line from that manifest below:
 <pre>
 Import-Package: org.example.conflict;version="2.0.0",

@@ Line 7: / Line 7: @@
 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 checked out with svn and run by executing ''ant run''.
+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/examples/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 with svn 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

@@ Line 94: / Line 94: @@
 # A resolved exporter must be preferred over an unresolved exporter.
 # An exporter with a higher version is preferred over an exporter with a lower version.
-# An exporter with a lower bundle ID is preferred over a bundle with a
+# An exporter with a lower bundle ID is preferred over a bundle with a higher ID.
 Thus the 2.0.0 version of the library will still win over the library from the host environment because it has the higher version id.

@@ Line 80: / Line 80: @@
 </pre>
 This output shows that the OSGi plugin bundle executes a different copy of the conflict library that is used by the host application.  In addition the plugin bundle was able to determine that the source of the library was the ''org.example.conflict'' bundle which supplies version 2.0.0 of the conflict library.
 === Altering the imported version of the library ===

@@ Line 41: / Line 41: @@
 </pre>
 If this import is removed and the relevant conflicting package is loaded through the Bundle-ClassPath, the bundle still will not import the host applications conflicting class.
 Finally, and this is the technique that the example uses, the import can be controlled by using versions.  The bundle states that it wants to import version 2.0.0 of the conflicting package.  The version of this package from the host application is marked as version 1.0.0 and is therefore not sufficient.  This means that the bundle will look elsewhere to find the desired version of the package.  The advantage of this mechanism is that it allows other bundles in the same OSGi environment to use the host applications version of the conflicting library.

@@ Line 107: / Line 107: @@
       [java] -------------------- OSGi Shutting down --------------------
 </pre>
-Now the plugin bundle gets the same version of the conflict library as used by the host application.  In addition we see that the plugin bundle gets its copy of the plugin bundle from the system bundle, ''org.eclipse.osgi'' (bundle 0).
+Now the plugin bundle gets the same version of the conflict library as used by the host application.  In addition we see that the plugin bundle gets its copy of the conlict library from the system bundle, ''org.eclipse.osgi'' (bundle 0).
 === Removing the host application library fron OSGi ===

@@ Line 12: / Line 12: @@
 PluginImpl class.  The PluginImpl class then immediately starts up OSGi and the work of the plugin is then done in the OSGi environment.  The steps taken by this small example are as follows:
 # the '''host application''' starts (Host.main()).
-# the host application finds and initializes the '''host plugin'''.  For now  this is simulated with a simple proceedure call but a real host application would find the plugin by some means such as reading a host directory, loading jar files from that directory and then loading and initializing the classes from that directory.
+# the host application finds and initializes the '''host plugin'''.  For now  this is simulated with a simple proceedure call but a real host application would find the plugin by some means such as reading a plugin directory, loading jar files from that directory and then loading and initializing the classes from that directory.
 # as part of its initialization, the host  plugin starts the '''OSGi environment''' which then initializes the '''plugin bundle''' (''org.example.bundle'').  The plugin bundle then demonstrates that it can make calls to the host application  evironment and the conflicted library.