祝贺 WebLogic 团队发布了 WebLogic 10 的预览版，该版本通过了 Java EE 5 CTS。 很高兴看到 BEA 在 J2EE 1.4 出现偏差后，恢复了快速行动的传统。

这对 Spring 社区来说是个有趣的消息，因为 WebLogic 10 在内部使用了Pitchfork。 Pitchfork 项目是由 Interface21 领导并与 BEA 合作开发的开源项目，它在 Spring 之上实现了 EJB 3.0 拦截和 JSR-250 注入。 它在 WebLogic 10 EJB 容器和服务器的其他部分中使用，以满足新的规范要求，但不与 WebLogic 绑定。 Pitchfork 可以独立使用（尽管这不是其主要目标），也可以被其他应用服务器采用。

顺便说一句，Pitchfork 项目不应与德国乐队Project Pitchfork混淆。 最新消息：我刚刚发现他们有一首歌叫做It's Spring。 虽然我不是他们的粉丝...

使用 Pitchfork 意味着从 WebLogic 10 的运行时角度来看，每个 EJB 3.0 会话或消息 bean 也是一个 Spring bean。 BEA 做出此选择的动机是实现快速上市，并在尽可能的情况下基于经过验证的代码来实现新规范功能。 事实上，Spring 已经做了很多他们需要做的事情，这有助于他们实现积极的时间表。 它还有助于确保安全的升级路径。 许多新功能由 Pitchfork 在经过验证的 Spring 代码之上提供； 绝大多数经过验证的现有 WebLogic EJB 代码库保持不变。 当然，采用这种方法突显了 BEA 对 Spring 质量的信任。

从长远来看，在 WebLogic 上运行 Spring 的用户应该会受益于 Spring 在表面之下的使用，允许服务器在深层管理 Spring 组件（服务器已经有效地“原生”理解它们），并使 Spring 组件模型能够用于补充 Java EE。 EJB 负责人 Patrick Linskey 最近暗示了其中的一些功能

这种架构还为我们提供了一些机会，可以在更集成的层面上向 WebLogic Server 开发人员公开 Spring 组件... [例如] ... 在 WebLogic Server 集群中部署 Spring bean； Spring 会话复制（利用 WebLogic HTTP 会话复制）； WebLogic 安全性与 Spring bean 的集成； 基于 WebLogic 的 Spring bean 集群远程处理； 以及在 WebLogic Server 管理控制台中管理 Spring bean。 此外，我们在内部为一些引人注目的、面向外部的 Spring 集成功能奠定了基础，但我们尚未在 WebLogic Server 10 中公开这些功能。

在之前的预览中，可以访问服务器内部的 Spring 并实际使用它进行编程。 Spring IDE 团队充满活力的 Christian Dupuis 在第一个预览版发布时发表了博客，展示了每个 EJB 3.0 会话或消息 bean 也是一个 Spring bean，并且可以通过提供与 EJB 同名的 Spring bean 定义，将更强大的 Spring 注入和真正的 AOP 应用于这些组件，这是一种简单而优雅的方法。 我不确定这种机制在当前的预览版中是否有效，并且还没有时间进行检查； 我知道 BEA 的目标是首先发布一个符合规范的服务器，然后研究如何最好地打包和记录增值扩展。

很高兴与 WebLogic EJB 团队合作开发 Pitchfork 及其在 WebLogic 中的使用——特别是 Michael Chen 和 Patrick Linskey。 不可避免地，与 Patrick 的一些工作是在啤酒中进行的。

显然，我对 Spring 角度特别兴奋（尤其是我和 Costin Leau 参与其中），但 WebLogic 10 中当然还有很多其他重要的东西：特别是，将 Kodo/OpenJPA 作为 JPA 持久性提供程序合并。 该产品的核心是 Apache License 开源。 很高兴看到继续强调 QOS 功能，而不仅仅是 API 追逐：例如，自动 JMS 故障转移。 特别是大型企业客户通常更关心运营和正常运行时间，而不是规范级别。

过滤类加载器听起来特别受欢迎（如果来得晚的话）。 复杂应用程序中的 J2EE 类加载传统上是人间地狱——痛苦且真正阻碍了应用程序的移植，即使它们按照标准进行编码并使用可移植框架也是如此。 随着服务器（包括 WebLogic 和 WebSphere）越来越多地在内部使用开源，冲突变得越来越普遍，需要进行 hack 修复。 （就像 ANTRL 与 Hibernate 3 和 WebLogic 8.1 的冲突一样，可以通过使 WAR 中的库优先于服务器中的库来解决。） 看来 WebLogic 10 将在此处提供一个可靠的解决方案，该解决方案使特定应用程序能够以更灵活的方式过滤掉服务器依赖的类。