Spring破坏了JEE规范吗?

[TTS 编辑注：这是 TTS 论坛上的原帖。我现在把它放到 TTS 主页上来，就是认定这又会是一场非常有趣的口水打仗。 ]

原文请看：http://www.theserverside.com/news/thread.tss?thread_id=50477

 

正文：

 

 

首先，我不是 Spring 的反对者。我已经在许多项目中用到了 Spring ，并心悦诚服的认为它是一个伟大的框架。

 

 

我想就我实际工作中 Spring+JEE 的整合，来探讨一些实际中遇到的问题（或者说更具“学术”性质的问题）。当我第一次看 JEE 规范的时候，这些问题就开始萦绕在我脑中。虽然的让我很困惑啊，但却很有意义。我现在已经知道不可以直接往文件系统写内容了。 [ 注：在 EJB 中新建，修改，删除文件系统的文件是不允许的 ] 。但我却不知道，在 EJB 3.0 Spec 21.1.2 规范中指出：在 EJBs 中不允许使用 Class.forName() 或类似的方法。

 

 

规范指出：

l         不允许 EJB 去试图建立一个 class loader ；

l         不允许 EJB 去得到当前的 class loader ；

l         不允许 EJB 去设置当前的 class loader ；

l         不允许 EJB 去设置 security manager （安全管理）；

l         不允许 EJB 去停止 JVM ；

l         不允许 EJB 改变 input, output 以及 error stream( 流 ) ；

 

 

这就是 Spring 的第一个违反 JEE 规范的实例：当我要得到 Spring 中配置的 Bean 时，该 bean 会动态的用类似于 Class.forName() 的方法将其实例化。在使用这个方法，那么无论是显式还是隐式的都会得到一个 class loader 。我认为不允许动态实例化的意义在于应用服务器是想完全掌控应用程序，从而将资源等其它方面达到最优。你们怎么想的？我确实很想听听你们的意见。难道我对规范理解错了？

 

 

第二个违反规范的例子是在 J2EE 应用程序中使用 AbstractStatelessSessionBean 时发现的。规范中说： Stateless Session Bean 不允许被继承。这点我同意，尽管看上去过于“学术”，但我坚信这么做一定有它的理由。（ [ 注 ] 关于这一点，网友马上找到规范当场对质。实际上规范说是是： session bean 可以有父类或接口 ……. 一个 session bean 不允许将另一个 session bean 作为其父类 ………. ）

 

 

我还发现根本就没要 Spring+JEE 组合。

 

 

因为同样我还发现，一些 Spring Integration Modules 在不同的应用服务器下表现的比直接使用 Spring 更出色。 ( 比如说在 EJB 容器中加载 Spring Context) 。你们在用应用服务器与 Spring Integration Modules 整合时，有没有类似经验？你们觉得这样使用是不是就可以解决我上面我所提到的问题呢？