JSR 291：Dynamic Component Support for JSR291，这个消息虽然有点旧了，不过还是同样非常的令人振奋，OSGi成功的进入了JAVA SE领域，在Java新版本中必然会越来越多的看到OSGi的影子，JSR 291的final版本将在9月1日发布，其实它的内容基本就是OSGi Core的内容。
OSGi对于Spring产生了重大的影响，这个从Rod Johnson本人的一段话以及之前Equinox中的"Declarative Services Vs Spring"邮件中可以看出很多：
Senior Member Spring Team | | Join Date: Aug 2004 Location: London, UK Posts: 1,109 |
|
 OSGi support in Spring
We don't yet have a release date in mind, but there is already OSGi integration code in the Spring sandbox. As the Spring model already offers powerful extension points such as proxying FactoryBeans, this sits happily on top of the present Spring core, so we don't need to do a bunch of rework to productize it. |
从这段话中我们可以看出什么呢？说明 Rod Johnson也是明白OSGi将对Spring造成的冲击，只是Rod Johnson认为目前Spring 2.0的核心目标是完成之前定的目标，而不是去改变象Spring AOP、JDBC所基于的底层框架，也就是Spring Core，但这也暗示了Rod Johnson对于OSGi的认同。
再来看另外一篇Equinox开发者maillist以前的一篇关于"Declarative Services Vs Spring"的Mail，Equinox的开发者可是毫不给面子的说出来DS完全会替代Spring DI的话：
摘自Neil Bartlett的一段精彩的话：
"
With OSGi you always have to be aware that the services you depend on might go away, and possibly come back again
later. That's the essence of OSGi - it's dynamic."
"
On the other hand Spring has much more to it than dependency injection. It also has a number of very powerful libraries, eg for developing DAOs using JDBC or O/R mappers, an AOP library, remoting libraries, etc"
"
I've just been to a seminar given by Rod Johnson where he mentioned that they are working on OSGi integration with Spring, ie making Spring more dynamic so that it will work properly within an OSGi runtime. That's very exciting for me because I think that OSGi combined with Spring's rich framework and AOP features would be an incredible platform for enterprise services. It would blow away anything previously possible with J2EE and EJB.
Unfortunately Rod said that this functionality is probably something that will be in Spring 3.0, where Spring is currently in 2.0 M1. As an alternative from the OSGi side, DS could be made more powerful so it could replace Spring's DI capabilities, while still making use of the other two sides of the "Spring triangle". "
"
It goes on to reject OSGi R3 but is silent on OSGi R4. In fact all of the reasons given for rejecting R3 are not applicable to R4. So what is the need for JSR 277? It appears to be a case of "Not Invented Here" syndrome.We now have JSR 291 which aims to turn OSGi itself into a JCP-supported Java standard."
对于OSGi Vs Spring、DS Vs Spring这样的话题我不是那么的感兴趣，因为准备的来说，OSGi与Spring没有什么太大的可比性，真的要比的话也只有"Declarative Services Vs Spring DI"，而其他方面则是两者各有优势，所以我认为OSGi尽管确实对Spring DI会产生不小的影响，但Spring最为重要的一个优势"POJO Enhanced"并不是OSGi的方向，所以我觉得OSGi与Spring并没有冲突，反而我非常期待Spring与OSGi的结合，Spring与OSGi的结合的一篇文章可见：
http://opensource.atlassian.com/projects/spring/secure/attachment/11891/spring_and_osgi.html这篇文章写的非常好，点出了Spring与OSGi结合给彼此带来的好处：
- Better separation of application logic into modules
- The ability to dynamically deploy, update and undeploy modules in a running system
- The ability to deploy multiple versions of a module concurrently
- The ability to dynamically discover and use services provided by other modules in the system
- The ability to seamlessly leverage Spring value-adds in, and between, modules.
- The ability to seamlessly leverage OSGi value-adds without detailed OSGi knowledge or experience.
We believe that the combination of OSGi and Spring offers the most comprehensive model available for building enterprise applications
一个最明显的好处就是可以简单的将现有模块不做大的改动(或者甚至不做改动)移植到OSGi环境中，不过以目前Rod的说法来看，估计还有的等，毕竟那可是Spring core呀，即使是做桥接估计工作量也很大，或者可以自己先动手起来。