……我们从基本上说其实不盘算把Spring用户社区驱逐就任何偏向。我们仅仅是给用户另外一种选择。Spring的哲学是用户老是准确的。用户是伶俐的,他们完整分明本人的必要。不论用户是不是选择SpringSource使用平台,我们以为用户总会接待多一点选择的……
JavaEE6重点在模块性,这个偏向是准确的。极可能SpringSource使用服务器会在必定水平上切合JavaEE6。JavaEE6分红A、B、C三种规格(profile)。我们几近一定会完成A和B规格,C规格内里我十分断定将完成EntityBeans1.1模子和一些遗留手艺。我还不克不及说是100%断定,由于JavaEE6标准还没有定案。
传统的使用服务器模子正渐渐过期。BEA和IBM正在用OSGi慢慢从头完成他们的使用服务器。SpringSource如今就供应OSGi撑持。从统计数字上看,年夜多半人都不会部署到完全的平台上,他们部署到Tomcat。他们选择了Spring编程模子而非JavaEE。市场已作出了选择,成绩只是开辟者还要和服务器奋斗多长工夫。
- 它是第一个创建在古代手艺基本上的产物。切合JavaEE标准已不是登峰造极的方针。洁净的代码基本是我们的一项合作上风。我们在计划和完成中满意的是当今的需求,而不是10年前的需求。
- POJO编程是如今行业的偏向地点。已往POJO编程是被强行嫁接到别的产物上的。在我们的产物中,POJO编程是计划的条件。
- SpringSource使用平台接纳的OSGi手艺是下一代手艺的基本。
……JPA和JMS都撑持,但我们没有包括任何特定完成。关于JPA,我们撑持Hibernate、OpenJPA和Toplink。我们在OSGi情况中增添了对加载时织进的撑持,并且会尊敬使用的界限,因而不会心外净化使用间共享的库。不包含JNDI,我们用OSGiServiceRegistry来代替它。Servlets是经由过程内嵌的Tomcat来撑持的。JEE中有而SpringSource使用平台没有的工具包含EntityBeans等等。
这个平台引进了使用的观点,使用由一个或多个Bundle构成。使用中的包有明白的感化域,能够避免产生使用间的抵触。在使用把服务公布到OSGiserviceregistry的情形下,避免抵触特别主要,谁也不想见到服务之间产生抵触。
我们引进了Import-Library语句,因而在使用中利用第三方库变得加倍复杂。你不必要再写一年夜串不直不雅的Import-Package声明,Import-Library能够主动为指定的库引进一切必须的package。像HibernateJPA如许的库还能够跨多个Bundle,可见Import-Library的确物有所值。
至于为了让SpringDM在平台中运转而举行的扩大,为数未几。
SpringDM掌控下的Bundle(SpringDMpoweredbundles)是包括META-INF/spring/*.xml文件的一般OSGBundle。Bundle启动的时分META-INF/spring/*.xml文件会主动成为该Bundle的ApplicationContext。SpringDM供应了一种机制让各Bundle经由过程SpringNamespaceHandler导进和导出服务。
一个PAR(PlatformARchive)实质上是一组OSGiBundle,一般个中有一部分是在SpringDM掌控下的。这些Bundle配合构成了一个逻辑上的使用。编程的时分完整是地道的OSGi、Spring和SpringDM——PAR没有改动甚么。
复杂来讲我们制止做如许的事。Buddy类装载、静态import、require-bundle,这些我们都明白躲避,由于保持分歧的类空间太坚苦了。我们也不会供应任何专有的替换机制。
相反,我们给Equinox增添了一些初级的钩子,以完成典范的场景下的资本装载。我们扩大了类装载来撑持加载时织进,而且把装载语义丢到一边。我们利用contextclassloader,让第三方自始自终地看到类。PAR是个中的中心脚色,由于它界说了高低文类装载和加载时织进的可见局限。
关于一些最糟的情形,我们会供应修补版的库,让它们能在OSGi中事情。修补版的库能够经由过程SpringSourceEnterpriseBundleRepository取得,我们的修正也会提交回响应的项目。
欢迎光临 仓酷云 (http://www.ckuyun.com/) | Powered by Discuz! X3.2 |