Quick OSGI tutorial

This project houses code acompaning a short OSGi training / workshop / tutorial. To be used as quick introduction to main OSGi abstractions and usage.

How to use it

This is to be used as supporting materials during a quick workshop. The idea is that participant checks out a initial version (marked with tag 'initial') and then follows the steps outlined by the trainer.

Other tags can be used in case of problems to bring the project to a know good state at any step of the training.

Tags descriptions

The tags and the corresponding state of the application. Start with checking out the first tag:

• git clone git@github.com:LukasWysocki/osgi-1hour.git

• git checkout S1

after that we will code together.

If you ever "get lost" on the journey we will checkout one of the other tags to get back on track.

S1 initial

The initial NON osgi two module maven project.

Goal at this step is to OSGi-fy the project. We want two bundles, client depending on provider. We want to "start' the client bundle for it to print a welcome message every few seconds.

• Look around the project

• Build with mvn clean install

• Run. Go to name-client directory and execute mvn -q exec-exec

• Change maven pom.xml files to build jars instead of bundles.

  • Change packaging

  • Uncomment Felix maven-bundle-plugin

  • Add bundle activator for name-client

  • Configure bundle properties

• Download Apache Felix OSGi framework and unpack resulting in new felix-framework-VERSION directory

• Build the bundles, use the felix CLI commands:

  • install ../PATH_TO_BUNDLE/bundle_name.jar

  • start BUNDLE_NUMBER

  • Commands that will be also useful are: stop, bundles, bundle, uninstall.

• Run Felix. Go to felix-framework-VERSION directory, run java -jar bin/felix.jar.

• Observe…​ fix bugs, repeat

S2 Vanilla OSGi

Just OSGi core based bundles, one depending on another, static.

Goal at this step is to replace the static "package" dependence of client on provider and replace it with dynamic dependency on a service exposed from provider.

• Register a NameProvider service in a new Bundle Activator in name-provider

• Use that service in name-client

• Remember about adjusting bundle definitions in pom.xml files

• redeploy in Felix…​ fix bugs, repeat

• try stopping the name-provider…​ name-client works — good or bad?

S3 a service, still static

We have a NameProvider service and we are using it, but we are not aware of it’s state changes (we could use a broken service).

Goal of this step is to react dynamically to the service being stopped.

• When name-provider bundle is stopped, make the DefaultNameProvider throw an exception to simulate closed resources.

• Observe the NameProvider service availability changes in name-client.

• redeploy in Felix…​ fix bugs, repeat

• try stopping the name-provider…​ observe name-client

S4 a service, with dynamic client

Now our NameClient is dynamically reacting to the registration and de-registration of Nameprovider service.

Goal of this step is to get rid of entire code that is acting as plumbing. Construction of objects, listening for availability of NameProvider service. We want to be left just with out buisness logic.

To do that we will use blueprint. We wil use it for dependancy injection including injetion of NameProvider service.

S5 service, and dependencies managed by blueprint

We have the services and dependencies dynamically managed by bluprint. We have no dependencies on OSGi in our code.