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呀，即使是做橋接估計工作量也很大，或者可以自己先動手起來。