Spring One (day3) : OSGI

This presentation nicely sums up OSGI.
Key assets are:

• Visibility: a bundle is a black box if not explicitely specified. Nice but does not fit with the current classloading designs where everything is in the same space (more or less)


• Operational control: see modules and their status, install, activate,...bundles.


• Dealing with dynamics: types and services can be exported and contributed (passive and active contribution respectively because services changes are dynamically seen).

Then what about OSGI and Spring?
How do you split applications into a number of OSGI bundles
Bundles need: instanciation, configuration, assembly, decoration.
This should not be coded, this is (mostly) boiler-plate code.

The purpose is to keep the Spring development model.

Main entrypoint there is an OSGI bundle-based application context.

Interesting thing is that beans can easily be exposed with a specific namespace (<osgi:service/> and <osgi:reference/>) and all the lifecycle and (re)binding of services is dealt with by Spring OSGI.

The ConfigurableBundleCreatorTests are interesting for integration testing. It can run the test of your code inside of an OSGI container. This is really a great progress, mostly if one can set it up for testing Eclipse plugins...

Provisioning with Maven and Ivy is also a catch and is planned for after version 1.0 (part of Maven support already is included in pre 1.0 though).