不是Jdon搞对立，是Spring自己搞对立，without EJB，本身词语含义已经有黑与白的关系了，为何又总是反复申辩。
>大多数的项目中普通需要的是像Spring这样的轻量型容
Spring是轻量型容器吗？ 单一个实例配置曾单态还是多例，这个问题我想很多初学者就无法一下判断准确。至少，我个人认为Spring是伪轻量容器。
>EJB是失败的东西
EJB怎么是失败的东西，大量的人在使用啊，如下：
http://www.jdon.com/artichect/EntitBean.htm
再建议看看这篇文章，从模式角度理解Spring，就不会对之有神秘的感觉。
http://www.jdon.com/jive/article.jsp?forum=91&thread=16595
EJB并不是失败，而是有些方面有些问题，像持久化，开发效率，可测性等都不怎么样，EJB并不完善，这是事实。
这个概念实现的Spring/picoContainer可以寄生在EJB或WEB容器，从而在应用系统和容器之间又形成新的一层，这样，用户的应用系统可以配置在Web容器运行，也可以配置在EJB容器下运行，用户自由选择余地大了，这是Ioc产品最大的优点。
作为Ioc模式微内核的实现Spring最大的缺点是引入Singleton，这点是另外一个同样实现picoContainer极力反对的，既然是Ioc微内核容器，微内核容器本身就是单态，唯一的，那么其中实例再无需单态了，但是Spring提供这种选择，容易引起初学者误用和以后性能问题。
> container，那么我们就要求有一个好的Web容器提供Cluster?
> 持，但是遗憾的是，目前J2EE标准中并没有和涉及Web容器的?
> 何Cluster定义或接口，所以造成有的Web容器提供Cluster，?
> tomcat有一些，jetty比较好，大部分商业化产品如Weblogic?
> 没有，它们把Cluster集中在EJB层了。
这个话我们私底下说说就好，如果让BEA的同志们听到没准他们要生气的。下边这篇文章不妨看看：
最大化BEA WebLogic Cluster的性能、可用性和安全
> EJB怎么是失败的东西，大量的人在使用啊，如下：
> http://www.jdon.com/artichect/EntitBean.htm
我那天在TSS看到这篇原文，有一句读得不太懂，看banq的翻译好象也一带而过，想请banq再解释一下，可否？
what with everyone and their brother (and their brother's friend's cousin) being happy to publicly whine and moan about what a pain EJBs are
If you need distributed transaction support, a JTA implementation provided by a
high-end application server is as essential in an IoC + AOP world as it is to EJB.
这句话翻译是“很多人包括他们周围的“兄弟”都乐于公然地抱怨和埋怨痛苦的EJB是：”。
我们已经看到很多人没有使用过EJB，但是附和在其他人后面一起抱怨EJB，其实在他们抱怨的时候，EJB本身已经在变化了。
好像这个话题不适合在这个帖子讨论，这里只是研究Spring，就此打住。
我一直在强调，并不是EJB 3.0和Spring一致，他们都同是新的设计思想的产物。这如同类图中继承关系一下，都是抽象思想实现，两个都是儿子，一个先出生，一个后出生，老二象老大，是因为他们是同一个老子生的，但不能断章取义说，老二模仿老大的；或是从老大那里复制的。
这就象美国在先进科技和思想指导下最先研制出原子弹，而中国过后也在同样的科技思想下研制出原子弹，那么就说中国的原子弹和美国原子弹一致了，或者说就是他那个样子。
Ioc模式理解可见这个连接：
http://www.jdon.com/jive/article.jsp?forum=91&thread=16595
另外EJB 3.0也不是可望不可及的，JBoss ejb 3.0已经可以在JBoss 4.0下运行使用，见这里连接：
http://www.jdon.com/jive/thread.jsp?forum=16&thread=16817
我前面已经指出，Spring目前版本缺点是引入Singleton，关于实现单态功能，EJB处理有其技巧，所以，在EJB环境中，是没有单态这个概念的，这也是为什么研究Petstore的人发现，serviceLocator有两种，一种是Web的单态，另外一种是EJB，这个问题，在Jdon很早时就讨论过了。
我也替Spring研究一下，引入Singleton是不得已而为之，实在想不出什么好办法为用户提供单态服务功能了。
目前设计领域大家已经普遍认识到Singelton的害处和危险，在Jdon的 “Java多线程 集群 并行模式 ”版块也有多个帖子讨论了单态对性能可能导致的影响，如果初学者再误用同步synchronized语法，整个系统可能变成单用户系统。我通过实践案例发现，初学者在做大系统时，特别喜欢用Singleton类和静态类，这是很现实的情况。
每次设置一个POJO的Spring配置时，脑海里都要考虑一下，是设置单态还是Pool，这个就如同使用EJB时，每次考虑是使用有态Bean和无态Bean考虑一下，因为EJB无单态，所以，比较容易选择Pool支持的无态Bean，但是如何在EJB实现全局唯一变量就费点思量。
dabb在这个帖子提出的问题就属于这种情况：
http://www.jdon.com/jive/thread.jsp?forum=16&thread=16893
从上面讨论，我们也看到，使用Spring并不简单，不是Spring框架或EJB做得不够好，是因为现实系统情况是复杂的，Spring或其他什么高级框架提供的选择越大，用户使用Spring这些框架和自己具体应用结合时，需要考虑得就越大，这增加了实际使用的复杂程度，所以我说，Spring这样框架其实并不能算轻量的（不是我一个人意见，我也看到有老外的同样想法）。
这样的讨论在 Java多线程 集群 并行模式 版块以前讨论很多，这里有一个贴供参考：
http://www.jdon.com/jive/thread.jsp?forum=121&thread=15399
第一，业务逻辑的原子性不应该用业务代码中的synchronize来保证。banq很熟悉EJB，你当然知道，EJB根本不允许使用synchronized关键字，业务逻辑的原子性是靠transaction infrastructures来保证的。那么，换到与session bean对应的POJO service component这里，你怎么会忘记了这个原则，却想在业务代码里面写synchronized呢？既然EJB里面写synchronized会导致undefined的结果，难道在Spring这里不是一样的吗？
第二，设若你的业务代码确实需要synchronize，我请问了，这样一个thread aware的对象，你怎么能把它交给容器――不管是Spring还是EJB容器――去管理生命周期？没错，开发集群、并行等基础代码时我们确实需要synchronize，你会把这些逻辑放在session bean里面去吗？
banq很熟悉EJB，你应该很清楚，即便EJB社群也已经公认：最有价值、最成功的EJB尝试就是stateless session bean。因为stateless，所以immutable，所以thread unaware，所以不需要synchronize，所以可以用任何形式的生命周期、任何形式的transaction infrastructure来管理。Spring管理的正是stateless business components，何苦要用stateful的、thread aware的观点来吹毛求疵？照这个逻辑，如果我在session bean里面写上synchronized关键字，恐怕结局不仅仅是“变成单用户系统”这么简单吧――具体会怎么样，banq应该比我更清楚。
这句话我不是很明白。照我理解，如果对象本身是immutable的（因此没有使用同步语法），不管多少个线程使用它，根本不会有排队，所以效率都是一样的。举个最简单的例子，String常量对象都是Singleton的，比如不管你在多少个地方声明 String s = "Hello"，得到的都是同一个对象实例。如果照你的说法，岂不是这样也会降低效率？至于事实究竟是怎样，各位自己写个程序试试就知道。Singleton究竟为何降低效率，恐怕banq得把前几年JavaWorld那几篇文章翻出来仔细看看再说。