Eclipse Ecosystem

A blog devoted to promoting the Eclipse ecosystem

Monday, May 08, 2006

Spring support for OSGi

There's been a lot of interest in the Rich Server Platform proposal, Equinox, and Eclipse's OSGi support in general. Server side pluggability with Eclipse. Cool stuff.

The Spring team have a new feature open for OSGi support in Spring. You can read about it here. Very cool stuff.

- Don


  • At 11:11 AM, Blogger Neil Bartlett said…


    I'm not sure if the Spring support for OSGi will be all that valuable. Spring containers are still (essentially) statically wired dependencies, and the only enhancement that has so far been built is to allow for beans to be retrieved from an OSGi service. It only works with "zero-or-one" cardinality and it doesn't perform any of the dynamic activation/deactivation and "cascades" that you can get with Declarative Services.

    One of the main purposes of Spring is to simplify programming through dependency injection and enabling the use of POJOs, and it was certainly true that earlier releases of OSGi had a programming model that was challenging to use correctly.

    But now with Declarative Services, OSGi has dependency injection and POJO support, and is furthermore dynamic... in other words, it's better than Spring.

    Having said that I am still using a lot of Spring code, eg their JDBC framework, their remote EJB proxies, etc. Just not their IoC framework. Fortunately Spring is very well designed and modular, making it easy to use as much or as little of it as you like.

    - Neil

  • At 8:35 AM, Blogger Adrian Colyer said…


    I see two key parts to supporting OSGi's "dynamic" programming model. The first is dealing with services that come and go, the second is supporting 'delayed activitation'.

    Spring deals with the first issue by not injecting a direct reference to an OSGi service, but by proxying that service using Spring AOP. The proxy listens to service events and can track changes to the service in a manner that is transparent to the user. The sandbox code doesn't currently support multiple cardinality, or full "dynamic" mode (obtain the service reference afresh on every invocation), but these will be added as soon as the code gets some more attention (it's in a *very* early state at the moment). The code update will use the OSGi ServiceTracker to track the services(s) being proxied.

    For the second issue (delayed activation) we will add an additional means of bootstrapping a Spring application context inside OSGi where the context itself is an OSGi service managed by declarative services. Thus a context won't be activated until it's references (including parent context if specified) are satisfied).

    Spring's IoC capabilities are still way beyond what you get with declarative services, which offers only a simple injection mechanism for OSGi services and basic properties.

    Fortunately it is possible to use Spring + OSGi + DS together (even with Spring & DS configuration in the same XML file when we are done) so the strengths of both platforms can be combined.

    In terms of "enhancements" offered by Spring AOP, it's also not true to say that the only enhancement (even in the very early sandbox code) is allowing for "a bean to be retrieved from an OSGi service". In addition to the proxying (mentioned above), the sandbox code also supports exporting of Spring beans as OSGi services (in a similar vein to the JMXExporter), automatic activation of a Spring application context within a bundle, publishing of an application context as a service, use of a context published by another bundle as a parent context, support for a bundle-based implementation of Spring's resource abstraction, and a BundleContextAware interface if you really do need to write code that is aware of executing in an OSGi environment.

    I have it on my todo-list to write a whitepaper describing Spring's goals and design for its OSGi support, I hope to be able to carve out the time for that real soon...

    Regards, Adrian.


Post a Comment

<< Home