August 4th, 2009 | Published in development
As I mentioned a few weeks ago, we have about 120 modules (bundles) that are part of our regular build process. Almost all of those bundles use Spring and Spring Dynamic Modules to wire their dependencies and configuration together.
Spring is used to automatically inject configuration settings into components (in conjunction with Apache Commons Configuration) as well as to inject the particular implementation into components where multiple options exist (such as database persistence, caching layers, etc.).
Many of the major components in the system are exposed as OSGi services and so we use Spring DM to automatically register and consume those services without coupling our code directly to OSGi. Spring DM is invaluable at helping to “damp the use of services” (as SpringSource’s Glyn Normington put it at one point), meaning that by giving you a dynamic proxy instead of a reference to the real service, your app can better tolerate the perturbations caused by services coming and going.
I don’t have much else to describe about unique work we’re doing with Spring DM because the reference manual is so comprehensive!
- Keep your code decoupled from OSGi by relying on Spring DM as the glue between your app and the OSGi framework.
- As suggested by the Spring DM documentation, split your application contexts into two files: one to contain the standard Spring bean definitions, and a second to contain the OSGi specific beans. This will make it easier to test and substitute mocks in place of real OSGi services.
- Create a parallel set of “test” contexts in the test hierarchy Maven has (src/test/resources) that mock certain objects or use.
- Create Spring integration tests to verify that your application contexts are correct (in particular, see the Spring TestContext Framework section of the reference). Utilize OSGi integration tests in addition to confirm that your services and service references are defined correctly.