Taming Beastly Web
Applications with
Server-Side OSGi
Don Brown, Atlassian

It starts so simple. . .

Then this happens. . .
SOAP interface REST interface
IRC interface Slooow deployment
Microsoft Excel export and
import Report builder
50+ third-party libraries and frameworks
PKI card authentication
Thousands of classes

Solution: Plugins
Application
Plugin Framework
Excel REST IRC SOAP
Plugin Plugin Plugin Plugin
Report PKI Auth
Plugin Plugin

Anatomy of a Plugin
Plugin JAR
Java
Utility JARs
Classes
Resources
XML
(images,
Descriptor
css, etc)

ls myplugin.jar
./com/myplugin/HelloWorld.class
./resources/logo.png
./META-INF/lib/util.jar
./plugin.xml

plugin.xml
<plugin key=”my.plugin”>
<plugin-info>
<version>1.0</version>
</plugin-info>
<servlet key=”helloWorld”
class=“com.myplugin.HelloWorld”>
<url-pattern>/helloWorld</url-pattern>
</servlet>
</plugin>

Not just any plugin
framework . . .
. . . Now Open Source (BSD)

Right, but what does this have
to do with OSGi?

What if your plugins
need plugins?
Application
Plugin Framework
Excel REST IRC SOAP
Plugin Plugin Plugin Plugin
Report PKI Auth
Plugin Plugin

Want: inter-plugin
communication
Report Plugin
Report Report Built-in
Services UI Reports
Users Sales Usage
Reports Reports Reports
Plugin Plugin Plugin

Want: dynamic
deployment
plugins
WEB-INF/lib

Want: application and
plugin isolation
Application
Internal External Internal
Services Services Resources
Excel REST IRC SOAP
Plugin Plugin Plugin Plugin
Report PKI Auth
Plugin Plugin

Want: application and
plugin isolation
Application
Internal External Internal
Services Services Resources
Excel REST IRC SOAP
Plugin Plugin Plugin Plugin
Report PKI Auth
Plugin Plugin

OSGi Basics
Dynamic module system for Java
Features:
• Service registry
• Lifecycle model
• Bundle dependency system
• Optional security layer

OSGi Terms
Bundle - Jar file with special OSGi entries in its
manifest and containing classes, resources, and
other jars
Lifecycle - States a bundle goes through:
uninstalled, installed, resolved, starting, stopping,
active
Service - An object instance exposed under the
one or more interfaces it implements and a map
of properties

Bundle Manifest
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

Bundle Lifecycle

OSGi Services
Key: “com.foo.MyInterface”
Instance: com.foo.MyService
Properties:
name => foo
someProperty => someValue

What does that mean?
• Upgrade bundles (think super jars) at runtime
• Bundles can depend on other bundles at a
service, package, or jar level
• Bundles can hide packages from other bundles
and version exposed packages

So how does OSGi
help us?

1. Ability for plugins to
depend on each other
Plugins can generate their own OSGi headers or:
<plugin-info>
<bundle-instructions>
<Require-Bundle> org.otherPlugin;bundle-
version=\"[3.2.0,4.0.0)</Require-Bundle>
<Import-Package>
*,org.otherPlugin.api;version=”[3.2.0,4.0.0)” </
Import-Package>
</bundle-instructions>
</plugin-info>

2. Ability for plugins to
define extension points
1. Plugin A exposes its implementation:
<component key=“foo” public=“true”
class=“org.bar.FooImpl” interface=“org.foo.Foo” />
2. Plugin B imports the service:
<component-import key=“foo” interface=“foo.Foo” />

3. Better insulate plugins
from product changes
• Host applications can decide which versioned
packages to expose to plugins
scanner.addPackageIncludes(Arrays.asList(
“com.atlassian.*”,
“org.apache.commons.*”));
• Host applications expose specific host
components:
<bean name=\"foo\" class=\"com.atlassian.
FooableBean\" plugin:available=\"true\" />
Or
@AvailableToPlugins
public class MyManager implements Manager
{...}

Plugins 2

Why should you care?

Built for integration
Shipped today with Atlassian applications
with different:
• Dependency injection libraries
• Web frameworks
• Persistence frameworks

On to the code . . .

Takeaway: Use plugins
and OSGi to tame your
beastly apps

Questions?
http://studio.atlassian.com/wiki/display/PLUG
http://felix.apache.org