My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox


March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture


July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response ( to the @mreinhold #jigsaw announcement ( 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

OSGi & Spring

Filed Under Architecture & Design, Java, OSGi, Platforms |  

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 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.


2 Responses to “OSGi & Spring”

  1. OSGi Progress : Software & Technology on November 13th, 2008 5:49 am

    [...] the last six months, it’s significant. First came Spring Dynamic Modules, which I showed in a previous blog entry. Then SpringSource Application Platform. Then SpringSource dm Server. And now the SpringSource [...]

  2. OSGi and Embedded Jetty : Software & Technology on February 2nd, 2009 7:25 pm

    [...] Felix, the OSGi runtime. As with my previous posts (Simple OSGi Service, OSGi & Modularity, and OSGi & Spring), I’m trying to use the simplest tools for the job to maximize the experience. That means [...]

Leave a Reply