Spring - OSGi Integration Milestone 1 Released

Posted by James Kao on Apr 16, 2007

Sections

Development,

Enterprise Architecture

Topics

Java ,

Enterprise Architecture

Tags

Spring ,

OSGi

Milestone 1 of Spring - OSGi was released and provides support for deploying Spring applications in an OSGi environment. OSGi's focus on dynamic modules presented some unique challenges to the Spring integration team:

One of the biggest challenges when adopting OSGi is dealing with its dynamic nature. Services (which are are simple object instances) come and go and your application has to deal with that. The solution is not straight forward, depends from case to case and requires an application-wide scope just like exception handling and transaction do. Classloading restrictions, enforced by the modularity mentioned, combined with AOP can cause a lot of grief and force the developer to create hacks, thus throwing out the window the benefits OSGi provides. These are just a few examples of the things we are addressing in Spring-OSGi which in the end, should allow a smooth adoption path to OSGi.

Some of the key features in this release are:

OSGi Application Context
Whereas OSGi is based on bundles which are independent modules, Spring-OSGi adds an application-wide context that gives developers access to the OSGi context that hosts the application.

Resource Abstraction
OSGi adds an abstraction layer to the classpath that utilizes a URL scheme that can vary from implementation to implementation. Spring-OSGi encapsulates this scheme and provides a portable lookup interface.

Dynamic Service Support
Through XML configuration, turning any arbitrary object into an OSGi service is significantly streamlined.

Integration Testing
Spring-OSGi adds a testing infrastructure built on top of JUnit that makes running tests from an IDE that execute inside of the container much easier.

Hal Hildebrand noted that the JUnit support was particularly noteworthy:

Basically, the issue with any in-container testing is getting your unit test to run inside the container. This requires setting up and starting the container, of course, deploying your test code (in the OSGi container case, the bundles you need for your test scenario) and then there's the JUnit test itself. Now you have to remotely trigger the running of the test and somehow get the results back from the test run.

Costin's framework does all this with a very slick framework which sets up and runs the OSGi container in the same process, wrapping your JUnit test class within an automagically generated OSGi bundle. The end result is that you now have in-container testing which can be run as any JUnit test is run - from Ant or from Maven, or from within your favorite IDE. As I said, this is very cool and you have to actually play with it to believe it. There's nothing even approaching it for any other container.

• Older >