Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

OSGi & Spring

05.06.2008
| 10534 views |
  • submit to reddit

It’s time to move on and show the simple elegance Spring brings to OSGi development using the HelloWorldSpec sample from the OSGi & Modularity post. But first, a little primer on Spring Dynamic Modules. Spring DM is not an OSGi implementation. Instead, Spring DM aims to make working with OSGi easier just as Spring makes the world of Enterprise Java simpler. One of the more striking characteristics of Spring DM is that it removes most your code’s dependencies on OSGi by taking care of the OSGi plumbing. To function in an OSGi runtime environment, the Spring .jars have been packaged as OSGi bundles.

The easiest way to show this is by expanding on the HelloWorldSpec sample from my previous post. Reviewing the HelloConsumer and HelloServiceImpl classes reveal that each are rather tightly coupled to the OSGi API. As we’ll soon see, using Spring removes those dependencies, making the Spring edition of HelloConsumer and HelloServiceImpl simple POJOs. Of course, the dependency on OSGi has to live somewhere, and for those familiar with Spring, we know it lives in the Spring configuration files.

The Spring DM configuration files live in a META-INF/Spring directory, which you can see in my Google Code Repository for the HelloWorldSpecSpring project. There are two files, and each are described below:

It isn’t necessary to separate the configuration into two separate files. However, experienced Spring users typically separate configuration elements to making management and testing easier. In this case, the two configuration files allows me to test the helloService bean outside of the OSGi runtime.

Since Spring is now managing the service within the Felix runtime, I have to install the necessary Spring bundles to Felix. As with the other examples, I’ve done this for you within the HelloWorldSpecSpring project. Of course, when starting Felix, you can always create a new profile by entering a different profile name and install the bundles yourself. The bundles within the SpringLib directory are those I found were required to ensure the Spring DM modules resolvd correctly. If you do choose to create your own profile, it’s likely you’ll have to modify the config.properties file to point to the location of your Felix runtime, which means you’ll have to download Felix to get these bundles since I only include the Felix runtime in the HelloWorldSpecSpring distribution, not the bundles. You won’t have to do this if you use the HelloWorldSpecSpring profile because the bundles have already been installed.

After installing the client.jar and service.jar, I should be able to perform the execute same start, stop, and install sequence described in my earlier post on OSGi & Modularity, and receive the exact same results. Except this time, Spring is managing the dependencies on the OSGi API and my classes remain simple POJOs. Spring’s simple elegance helping yield a higher quality design with fewer dependencies on the OSGi API.

For other relevant articles visit http://techdistrict.kirkk.com or http://apsblog.burtongroup.com/

Published at DZone with permission of its author, Kirk Knoernschild.