Spring和EJB的竞争发展历史(2007),Spring1.2/2.0移植到Spring2.5 zt

http://www.javastar.org/thread-49-1-1.html spring和ejb的竞争发展历史（发表于 2007-1-23 01:16）
spring和ejb的竞争发展历史(内容为转载，不代表本人观点，原作者robbin)
Spring自从2003年发布以来，一直是Java开源框架的奇迹之一。从2000年开始，伴随着B/S架构逐渐引入企业应用软件开发的领域，Java就逐渐成为企业应用开发的主流技术，一直到2003年，Struts＋EJB一直是Java技术架构的不二选择，然而这一切随着2003年Spring以without EJB的面目出现之后，一切都开始改变。
大概从2003年下半年开始，Spring＋Hibernate就开始甚嚣尘上，似乎那时候的Spring和Hibernate尚且不足以动摇J2EE规范以EJB为核心的领袖地位。但是2004年5月份，吸收了Spring/Hibernate框架优点的EJB3 JCP委员会的成立，事实上宣判了Spring对EJB2的终结，EJB3则更像是Vendor们的一种自救行为。
2004年到2006这三年时间以来，Spring取得了相当辉煌的成就，不但将EJB2赶进历史，而且牢牢确立了Spring作为Java企业应用开发的主流地位。而今，甚至对技术比较保守的金融电信行业，也开始言必称Spring，Spring已经成为Java框架的事实标准。
在2004年5月份之后，Hibernate Team开始和Spring公然决裂，这个事情放在两年多以后的今天来看，原因是昭然若揭的，背靠JBoss的Hibernate Team已经成为EJB3规范的一部分，而JBoss希望力推的以EJB3为核心的Java架构来成为未来的企业应用主流标准，这种情况演变至今，变成了Springframework和JBoss Seam的两种不同技术架构的竞争关系。
2004年5月份，EJB3规范的起步，对Spring未来其实有很大的威胁，但是EJB3规范历经两年时间的难产，终于在2006年5月正式发布之时，已经为时过晚了，抬眼望去，已尽是spring的天下。
有意思的是，大致展望一下未来，Java的企业应用开发还能遵循Sun和JCP制订的Java EE规范的道路走下去吗？如果不是这样，那么未来道路是什么呢？
观察一下Java社区几股大的势力，会发现一些有意思的现象：
IBM和BEA是Java社区的领导者，从2004年开始，IBM和BEA开始大肆宣传SOA，将他们的目光从应用服务器领域挪到了松藕合企业服务领域，开展SOA商业战略。与此同时，EJB3专家委员会的领导者也悄然变成了JBoss和Oracle，是IBM和BEA无力争取吗？当然不是。IBM和BEA已经看到了应用服务器市场和底层框架平台即将被开源占领，商业价值萎缩，因而审时度势进行战略转型。一方面押宝SOA战略，大肆炒热和培育SOA市场，另一方面也积极占领开源市场，IBM放出来WebSphere社区版本－Apache Geronimo，BEA干脆和Spring的咨询公司interface21合作，提供spring框架在WebLogic上的商业技术支持，如今EJB3对于他们来说已经形同鸡肋，就抛给别人嚼吧。
将EJB3当块宝的自然是应用服务器市场的跟随者JBoss和Oracle，一方面凭借ORM的先天优势，另一方面有出头机会也不能放过，EJB3委员会几乎成了JBoss和Oracle的天下。特别是JBoss，更加积极推出JBoss Seam框架，希望确立以JSF＋EJB3的架构树立Java开发的标准，用以取代Struts/Spring/Hibernate的流行组合，因而开启了EJB3和Spring 正面交锋的战争。
Java Vendor中另外一股势力Sun公司这两年则一直自顾不暇，在应用服务器领域几乎退出市场，直到最近才搞出来一个Glassfish，在开发框架领域也一直毫无建树，推出的JSF至今还很不成熟，难担大任，也许Sun都去忙着开源Solaris和JVM源代码了。
几个大的Vendor或战略转型，或自顾不暇，或忙于收购(Oracle)，Java开发领域的主战场被打扫一空，对决的双方换成了Spring和JBoss。对决的武器则是spring vs Seam。
Spring代表了不遵循通用标准，自己制订游戏规则，不依赖容器的一方；JBoss代表了遵循通用标准，但是锁定容器的一方。这场对决从2004年5月就开始上演，未来很长时间也会继续下去。不过Spring已经站在优势很大的地位上了。我个人觉得Spring会胜出这场对决，而Java企业应用开发的主流技术将倒向Spring这一边，而Vendor们官方制订的标准将被开发人员可怜的遗弃到一边。开源技术开始决定Java企业开发的未来走向。
大致对比一下两者：Spring vs EJB3，就会发现Spring从功能上面已经胜出很多了：
1、IoC容器spring胜出
Spring的IoC容器很强大，其bean管理功能超过了目前EJB3容器，配置方面Spring稍微复杂一些。不过对于全局性配置来说，XML要优于EJB3的annotation。
2、AOP能力Spring胜出
EJB3目前提供的AOP功能非常简单，本来已经无法和Spring相比，至于集成AspectJ的Spring2.0，就更加望尘莫及了。
3、事务管理方面EJB3稍微领先
Spring提供了很棒的本地事务模型，也可以集成JTA，但是不支持分布式事务，当然这种场景也非常罕见。
4、Web框架spring胜出
EJB3标准集成JSF，但是JSF并不成熟，和AJAX配合度也不好。Spring可以灵活集成各种Web框架和模板语言，自身也提供了相当强大的MVC框架，要是这还觉得不够，那么spring webflow，portlet support都拿出来，那么EJB3就必败了。
5、远程访问支持，大致持平
EJB3继承了传统的EJB远程访问能力，Web Services支持也不错；不过Spring提供了更多更灵活的选择，Java RPC，HTTP Invoker，Hessian/Burlap，WebServices。
6、框架集成能力，spring胜出
这是spring的传统优势项目，只要看看spring modules项目，看看n多第三方spring支持，就会发现spring现在的群众基础多么好，集成工作流，spring modules已经提供了方便的模板类，集成规则引擎，Cache，CMS，脚本语言，异步任务，安全验证框架。。。。。。EJB3有点望尘莫及的味道
7、JMS，JMX，JCA等，EJB3领先一步
这些传统EJB优势项目往往应用的不太多，EJB3仍然是领先的。不过令人侧目的是，Spring最近几个版本在连续追赶EJB这些传统优势领域，到Spring2.0为止，其JMS，JMX，JCA支持已经相当不错了，可以说传统EJB能够做的，现在Spring也可以做得到，为Spring一统江湖扫清了最后的障碍。
这几年除了Spring框架自身不断完善和延伸到传统应用领域，围绕在Spring周围的第三方框架也是越来越丰富，EJB3在annotation方面有些独到的优势，在一些传统领域，还领先spring，但是总体来说，EJB3为核心的J2EE5.0规范很难和Spring现在的2.0相匹敌，更何况Java的主力Vendor早已醉翁之意不在这里了，单凭JBoss的Seam，难以战胜spring。
我觉得Spring可能会越来越主流，甚至开始引领Java企业开发的未来发展道路，J2EE就靠边站吧，也许Java社区也到了开源社区说了算的时代了。

http://hi.baidu.com/by05/blog/item/e610b9fe8e22d4395c600891.html Spring和EJB终于统一融合
2009-04-12 16:56
Spring 和EJB争吵终于即将结束：Spring将支持EJB3.1标准，Spring will also be a full featured EJB 3.1 implementation for use in the WebLogic application server.这场融合将在javaEE 6实现，这个融合和当初Hibernate与JPA融合一样水到渠成。
Spring创始人Rod Johnson 说Spring 2.5的dependency injection annotations是学习得益于EJB 3.0的 @Resource 和 Google's Guice，我不知道他为什么没有提picocontainer，至少他的Spring 2.5开始直接大胆使用DI的auto wiring（而这个功能在Spring 1.X中还是可选功能），而2005年我的Jdon框架就完全是auto wiring。
Rod Johnson鼓励开发者使用EJB标准，比如 @PostConstruct 和 @PreDestroy annotations，因为他们是标准化的，Spring已经支持他们（Spring才支持它们？今天才明白？），这些都意味着Spring和EJB争吵的结束。
其实EJB的@PostConstruct @PreDestroy @Resource 这样annotations都可以在EJB2中找到影子和原根，表现语法不一样，但是内部机制原理是一致的。所以，以前没有学过EJB的，看来还是要补这一课。
PostConstruct和PreDestroy都是在对象生命周期开始以及结束让程序员能够进行一些状态管理，比如开始一些场景准备和加载，或者结束后，释放一些资源，防止内存泄漏，这些都是从EJB1.X 无态Bean开始就有的功能，不过当初是使用XML配置，并且无论程序员实现与否，一定要写这几个方法，现在通过注解 annotation 加在你需要实现的方法上，更加简洁方便。
所以，我以前说：如果说EJB1/EJB2X是一个定型的女孩的话；那么EJB3引入IOC/DI依赖注射和annotation以后，就更漂亮，更加吸引程序员接近她，也非常容易和其打交道了。
EJB从开始诞生起，因为高低各种原因，被高端和低端各种人怀疑打击，真正是遭受了不公平待遇.
高端专家比如Martin Fowler因为其不宜测试，提出POJO思想，认为对象应该不依赖平台，应该是一个个光溜溜来去无牵挂的，不继承任何框架接口等。不可否认POJO促进了EJB3变得更漂亮，但是EJB内在分布式计算组件的重点没有变。
在低端程序员中，EJB以其深奥的原理和超前的设计思维，更不能被他们理解，他们甚至以一种僵化思维来看：现实80%不是大系统，不需要集群分布式计算。
他们这种思维去炒股票肯定输得血本无归，因为，他根据他看到的80%股票下跌，20%上涨，因此决定自己是进入80%的股票还是进入20%股票，这种以过去经验的僵化思维来决定未来的策略和“守株待兔”没有区别，今天看到一只兔子撞死在树下，明天就在这里等，以为同样事情发生。
你今天做的系统在以后几年可能不需要集群，不需要对付大访问量，但是你能保证你做的每个系统都是这样，你为什么要等这个系统真的可能被某个风险资本看中，发展为全国系统，抗不住大访问量时，再去救它吗？为什么不在当初系统架构设计时，以较小的代价设计一个可伸缩的 有预先的系统呢？
我一直主张“数据库已死”，因为正如Hibernate创始人Gavin King说说：数据库是最不具有伸缩性的，不具伸缩,就是没有弹性，就是阻碍我们将整个系统设计成可伸缩 灵活系统的绊脚石，这样技术不宣布其死刑，又能如何呢？
我宣扬的这些思想是一个很高很深刻的架构思维，就像我们追求设计模式，因为软件不是将功能做好就够了，要考虑将来维护拓展时的方便，好不容易不少人接受模式，但是他们更多不知道为什么要使用模式。否则，他们就不会那么不理解“数据库好好的，为什么让它死，没用吗？”
所以，从Spring和EJB争论，以及最早的EJB CMP和Hibernate争论中，都可以看出国内大多数程序员盲目跟风，没有自己思维和观点的特点。
现在我们追求领域建模，认为数据表创建只是程序部署运行时实现的，而不是在程序编写之前或编写时创建的，EJB CMP最早提供了模型自动创建数据表的功能，但是大多数人只看到EJB这样一个超前产品的缺点，包括Gavin King本人，但是自从他进入EJB 3.0专家组以及他对EJB的逐步了解，他已经是EJB的拥护者，并推出基于JSF+EJB3的框架Seam。
我一直也奇怪，为什么EJB这样超前标准得不到大多数程序员的理解，不是EJB太高，而是我们程序员太弱，在面向对象上是空白，在分布式计算上更是幼稚。
对于那些盲从Spring的拥护者来说，原来他们说有了Spring就足够，不需要学习EJB，现在Spring 2.5新增的这些注解，同样他们付出学习EJB一样的精力，在我们程序员中，对对象生命周期 状态管理等极其薄弱.
因为面向过程背景的限制，变量函数在运行时情况是统一一致的，而java中一个类在运行是可以有多个实例，也可以有一个实例，每个实例能够存活多长时间，从什么时候开始创建诞生，如何能够被垃圾回收机制顺利回收，结束自己的生命周期，这些都掌握不到位。
从Spring和EJB这场争论中，从名义上看，是EJB标准取得了最终胜利，但是，也正是Spring和Hibernate的竞争，促进了EJB走向完美。Rod Johnson也从当初狂喊"J2EE without EJB"的大忽悠，转变到现在鼓励大家使用EJB标准，因为他明白了，可是他那些盲从者不知明白了没有。
没有明白的就开始嚼嘴皮子了，玩语言游戏：EJB3还是按照Spring写的标准呢？这完全是一厢情愿的想法：上面谈的Spring 2.5那些@PostConstruct注解早就在EJB3.0里就有，EJB3.0是先于Spring推出Annotation的，EJB内在的有态对象管理自从EJB1.X就有，Seam更是将EJB推向应用高峰。我们从Jboss Seam的受欢迎程度已经可见一斑，现在找工作，不懂Seam恐怕就象当初不懂Spring一样不时髦。
本人Jdon框架从一开始也提供了Session有态管理，当时我也在J道指出了Spring1.x无状态管理的缺点，虽然Spring2以后开始提供scope="session"，但是到现在2.5版本才提供缺省的依赖注射自动配对，可见Spring2以后版本在某些方面似乎在“补课”。
如果说Spring对EJB3有所促进的话，就是其依赖注射IOC/AOP设计思想。由于和AOP冠军ApectJ融合，致使其在AOP方面的强大是首屈一指的。可惜实践中我们发现，语言级别的AOP才可能是我真正需要的，我需要修改运行中对象的属性和方法，这些如果JVM能够提供将是一个跃进。
所以，无论是Spring向EJB汇合，还是EJB向Spring汇合，这些都已经不重要，因为他们已经不再分裂，而是一个统一名称EJB。从Spring诞生引起的潮动到今天与EJB合一的解释以及Seam的热捧等这一系列事件中，可以看出：如果我们程序员自己不具备深刻的OO思维，不具备高度的架构思想，不具备专业的软件设计思想，面对国外瞬息万变的各种思潮，就只能发生盲目崇洋，盲目跟风，甚至东施效颦

http://hi.baidu.com/by05/blog/item/66d100826d94a6aa0df4d276.html Spring1.2/2.0移植到Spring 2.5
2009-04-18 16:59
这部分包含一些细节问题，在你从Spring 1.2/2.0升级到Spring 2.5时可能遇到。
从Spring 2.0.x应用程序升级到Spring 2.5只需要简单的把Spring 2.5的jar复制到你应用程序目录结构中的合适位置即可。我们高度建议任何运行在JDK 1.4.2或更高版本的Spring 2.0应用程序升级到Spring 2.5，特别是运行在Java 5或更高版本上的，Spring 2.5带来了巨大的配置便利和性能提高。
从Spring 1.2.x升级是否平滑取决于你在代码中使用了多少Spring API。Spring 2.0删除了在Spring 1.2.x代码中标注为“deprecated”的绝大部分类和方法，因此如果你使用了这些类或者方法，你当然得使用替代的类和方法（下面有一个列表）。
在配置方面，Spring 1.2.x风格的XML配置是100%信心保证和Spring 2.5兼容的。当然如果你还在使用Spring 1.2.x DTD，你没办法使用一些新的Spring 2.0功能(例如scopes ， easier AOP 和 transaction configuration)，但是没有什么会出错。
建议的升级策略是将Spring 2.5 jar放入，以得到新版本的好处（例如bug修正，优化，等等）。然后，以一种循序渐进的方式，开始选择使用新的Spring 2.5功能和配置。例如，你可以开始用新的Spring 2风格来配置你的aspects，完全可以将其中的90%仍然使用老的Spring 1.2.x配置（引用1.2.x DTD）,剩下的10%使用新的Spring 2 配置（引用2.0/2.5 DTD或者XSD）。记住，将Spring 2.5类库替换后，你并不是非得升级你的XML配置不可。
支持的JDK版本
Spring 2.5对JDK 1.3已经不再支持，因为Sun官方从2006晚期已经正式将JDK 1.3淘汰。请升级到JDK 1.4.2或更高版本。
如果你必须使用只支持JDK 1.3的应用服务器，例如WebSphere 4.0或5.0，我们建议你使用Spring Framework版本2.0.7/2.8，它们仍然支持JDK 1.3。
Spring 2.5的Jar打包
在Spring 2.5中， Spring Web MVC 不再是 'spring.jar' 文件的一部分. Spring MVC以'spring-webmvc.jar' 和'spring-webmvc-portlet.jar'文件形式在发行包的 lib/modules 目录中存在。 另外，对Struts 1.x的支持被独立成 'spring-webmvc-struts.jar'。
注意: 经常被使用的Spring的DispatcherServlet也是Spring Web MVC框架的一部分。 因此，就算你只是为了远程访问（例如，暴露Hessian或者 HTTP调用服务）而使用DispatcherServlet,你也得将'spring-webmvc.jar'(或者 'spring-webmvc-portlet/struts.jar')放到'spring.jar'旁边去。
Spring 2.0的 'spring-jmx.jar' 和 'spring-remoting.jar'已经被转移到 Spring 2.5的'spring-context.jar' (针对 JMX 和非HTTP 远程支持)，部分转移到 'spring-web.jar' (针对HTTP 远程支持)。
Spring 2.0的 'spring-support.jar' 被改名为 'spring-context-support.jar', 更好的表达其真实含义。 'spring-portlet.jar' 被改名为 'spring-webmvc-portlet.jar',表明它是Spring Web MVC framework的子模块之一。 类似的, 'spring-struts.jar' 被改为'spring-webmvc-struts.jar'。
Spring 2.0的'spring-jdo.jar', 'spring-jpa.jar', 'spring-hibernate3.jar', 'spring-toplink.jar' 和 'spring-ibatis.jar' 被合并到Spring 2.5大粒度的'spring-orm.jar'中。
Spring 2.5的 'spring-test.jar' 取代了'spring-mock.jar',表达其对test context framework的强烈关注。 注意 'spring-test.jar' 包含了上个版本 'spring-mock.jar'中的一切，因此如果是单元或集成测试，可以直接取代。
Spring 2.5的 'spring-tx.jar' 取代了 'spring-dao.jar' 和'spring-jca.jar' 文件，表达其对transaction framework的强烈关注。
Spring 2.5 将其jar文件直接作为OSGi兼容的bundle。这使得在OSGi环境中使用Spring 更加方便，不再需要定制打包了。
XML配置
Spring 2.0的XSD在描述Spring XML元数据格式方面比先前的DTD更丰富。 旧的DTD仍然得到支持，但如果可能我们鼓励在bean定义文件头部引用XSD文件。
有一点被改变了，那就是定义bean作用域的方式。如果你使用的是Spring 1.2 DTD，那么你能继续用'singleton'属性。 如果你选择引用新的Spring 2.0 DTD，它不允许使用'singleton'属性， 那么可以用'scope'属性来定义bean的生命周期作用域。
Deprecated（淘汰）的类和方法
一些以前被标记为@deprecated的类和方法Spring 2.0代码库中被完全删除了。 Spring团队决定把2.0版本作为一个新的开始，那些被deprecated的代码应该被除去而不是在可预见的未来继续在代码中出现。
如前所述，如需了解全部变化，请参考Spring Framework 2.0发布包顶层目录里的'changelog.txt'文件。
下面的类/接口已经从Spring 2.0的代码中删除了：
ResultReader : 使用RowMapper接口代替。
BeanFactoryBootstrap : 考虑使用一个BeanFactoryLocator 或是自定义引导类代替
Apache OJB
Spring 2.0开始，请注意Spring主代码中的Apache OJB支持被完全删除了； 但仍然可以在Spring Modules项目中找到Apache OJB的集成库。
iBATIS
请注意iBATIS SQL Maps 1.3支持被完全去除了。如果你还在使用iBATIS SQL Maps 1.3， 请升级到iBATIS SQL Maps 2.0/2.1。
Hibernate
Spring 2.5中，对 Hibernate 2.1 和 Hibernate 3.0 的支持已经去除。请升级到Hibernate 3.1或更高版本。
如果你需要继续使用Hibernate 2.1或3.0，我们建议你继续使用Spring 2.0.7/2.0.8，这些版本仍然支持Hibernate的那些版本。
JDO
Spring 2.5中，对JDO 1.0 的支持被去除。请升级到JDO 2.0或更高版本。
如果你需要继续使用JDO 1.0，我们建议你继续使用spring 2.0.7/2.0.8，这些版本仍然支持JDO 1.0。
UrlFilenameViewController
从Spring 2.0起，UrlFilenameViewController所决定的view名字现在考虑了request中的嵌套路径。这是对原始 UrlFilenameViewController约定的重大修改，意味着如果你从Spring 1.x升级到Spring 2.x，并且你在使用这个类，你可能必须小小的修改你的Spring Web MVC配置。请参考UrlFilenameViewController 的类Javadoc，来查看新的view name determination的约定的示例。