BT

Spring - OSGi Integration Milestone 1 Released

by James Kao on Apr 16, 2007 |
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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT