OSGi is a dynamic module system for Java.
Take a look at the glossary for more terms and definitions.
A service registry is a map of one or more interfaces bound to object instances, with a set of properties attached to it.
Example of a service registration:
1 2 3 4 5
Key: "com.foo.MyInterface" Instance: com.foo.MyService Properties: name => foo someProperty => someValue
A lifecycle is the sequence of states a bundle goes through: uninstalled, installed, resolved, starting, stopping, active.
Most stages in the bundle lifecycle are familiar to plugin developers. OSGi adds the resolved step. This indicates that the OSGi system has connected up all the dependencies at a class level and made sure they are all resolved.
When you create an OSGi bundle, the manifest is where you declare information such as a bundle symbolic name (i.e. the plugin key) and the bundle version (i.e. the plugin version), etc.
You can import a package, and even declare that you need a specific version of the package. This is a nice way to declare your dependencies. For example, if your plugin uses Velocity, you can say you require Velocity 1.5 or greater.
You can export packages, i.e. make them available to other plugins and/or applications.
You can also define a class path for where you are putting your dependent JARs. Either you can continue putting all your dependent JARs into the default folder inside the JAR, or you can choose your own custom location.
Example of a bundle manifest:
1 2 3 4 5 6 7
Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.foo.Example Bundle-Version: 1.0 Import-Package: org.bar;version="1.3.0" Export-Package: org.foo.api Bundle-ClassPath: .,META-INF/lib/foo.jar
More: Managing Dependencies.
The Spring Dynamic Modules library (Spring DM) enables developers to build plugins with a consistent dependency injection across Atlassian applications.
Spring DM takes the service model of OSGi and simplifies it into Spring terms, making the dynamics of OSGi services a bit easier to work with. This is especially useful for developers who are already familiar with Spring.
Spring DM gives every plugin its own bean factory. You can:
For more information, see the Spring DM documentation.
1 2 3
<osgi:service id="fooService" ref="foo" interface="com.myapp.Foo"/>
1 2 3 4 5 6
<!-- bunch of XML namespace stuff skipped --> <beans> <bean name="foo" class="com.myapp.FooImpl"/> <osgi:service id="fooService" ref="foo" interface="com.myapp.Foo"/> </beans>
1 2 3 4 5
<!-- bunch of XML namespace stuff skipped --> <beans> <osgi:reference id="foo" interface="com.myapp.Foo"/> </beans>
Plugins can generate their own OSGi headers and use:
1 2 3
Require-Bundle: org.otherPlugin;bundleversion="[3.2.0,4.0.0)" Import-Package: org.otherPlugin.api;version="[3.2.0,4.0.0)"
Plugin A contains the interface and defines a service reference:
<component-import key="foo" interface="org.Foo" />
Plugin B exposes its implementation:
<component key="foo" public="true" class="org.bar.FooImpl" interface="org.foo.Foo" />