JSR 291：Dynamic Component Support for JSR291，這個消息雖然有點舊了，不過還是同樣非常的令人振奮，OSGi成功的進(jìn)入了JAVA SE領(lǐng)域，在Java新版本中必然會越來越多的看到OSGi的影子，JSR 291的final版本將在9月1日發(fā)布，其實它的內(nèi)容基本就是OSGi Core的內(nèi)容。
OSGi對于Spring產(chǎn)生了重大的影響，這個從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認(rèn)為目前Spring 2.0的核心目標(biāo)是完成之前定的目標(biāo)，而不是去改變象Spring AOP、JDBC所基于的底層框架，也就是Spring Core，但這也暗示了Rod Johnson對于OSGi的認(rèn)同。
再來看另外一篇Equinox開發(fā)者maillist以前的一篇關(guān)于"Declarative Services Vs Spring"的Mail，Equinox的開發(fā)者可是毫不給面子的說出來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這樣的話題我不是那么的感興趣，因為準(zhǔn)備的來說，OSGi與Spring沒有什么太大的可比性，真的要比的話也只有"Declarative Services Vs Spring DI"，而其他方面則是兩者各有優(yōu)勢，所以我認(rèn)為OSGi盡管確實對Spring DI會產(chǎn)生不小的影響，但Spring最為重要的一個優(yōu)勢"POJO Enhanced"并不是OSGi的方向，所以我覺得OSGi與Spring并沒有沖突，反而我非常期待Spring與OSGi的結(jié)合，Spring與OSGi的結(jié)合的一篇文章可見：
http://opensource.atlassian.com/projects/spring/secure/attachment/11891/spring_and_osgi.html這篇文章寫的非常好，點出了Spring與OSGi結(jié)合給彼此帶來的好處：
- 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
一個最明顯的好處就是可以簡單的將現(xiàn)有模塊不做大的改動(或者甚至不做改動)移植到OSGi環(huán)境中，不過以目前Rod的說法來看，估計還有的等，畢竟那可是Spring core呀，即使是做橋接估計工作量也很大，或者可以自己先動手起來。