Spring and OSGi R4.2
I've been scanning the early draft of OSGi R4.2, specifically RFC 124, "A Component Model for OSGi". I am delighted to see that the great work that has been done with Spring-DM will be formally adopted into the OSGi specification. Congratulations to Costin and Adrian who worked so hard on Spring-DM.
But what's not clear to me is that while Spring-DM is affecting the OSGi specification, how will the OSGi specification affect Spring-DM? Will Spring-DM be retired? Will it be morphed into an implementation of RFC 124?
What's even more mysterious to me is how well RFC 124 will integrate with Spring. I ask this, because as I look through RFC 124, it not only defines ways to publish and consume service ala Spring-DM, it also describes basic Spring-style dependency injection. The only difference is that instead of using
<bean>, OSGi developers will be using
<component>. Is the Spring framework itself being swallowed up by the OSGi specification? Surely not.
So, where does this leave Spring with relation to OSGi R4.2? If RFC 124 recreates Spring-DM and (at least to some degree) Spring DI, then where does this leave developers such as myself who work with both Spring and OSGi? Will I be able to use both Spring and RFC 124 together? Will I be able to inject a
<bean> into a
To a lesser extent, I wonder what this means for OSGi Declarative Services (DS)? Personally, I've considered DS deprecated in favor of Spring-DM, as Spring-DM does what DS does and more. Will RFC 124 trump DS?
Honestly, I've only had time to quickly scan RFC 124. Maybe all of the answers to my questions are there for a more thorough reading. And, since Adrian wrote the first draft of RFC 124 (and, I assume, contributed to all subsequent drafts), I am confident that these questions are answered somewhere--if not in RFC 124, then in other documents, e-mails, or forums.
I trust that RFC 124 is a good thing and that the Spring and OSGi communities will both benefit from it. I just have a few question that I'd like cleared up.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)