恭喜 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 质量的信任。

从长远来看，Spring 在底层的使用应该会使运行 WebLogic 的 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 许可证开源。很高兴看到持续强调 QOS 功能，而不仅仅是 API 的追逐：例如，自动 JMS 故障转移。特别是大型企业客户通常比规范级别更关心操作和正常运行时间。

过滤类加载器听起来特别受欢迎（尽管已经推迟了）。传统上，复杂应用程序中的 J2EE 类加载是地狱般的存在——痛苦不堪，即使应用程序遵循标准并使用可移植框架，也是移植应用程序的真正障碍。随着服务器（包括 WebLogic 和 WebSphere）在内部越来越多地使用开源，冲突变得越来越普遍，需要通过 hack 来解决。（例如，与 Hibernate 3 和 WebLogic 8.1 的 ANTRL 冲突，可以通过使 WAR 中的库优先于服务器中的库来解决。）看来 WebLogic 10 将在此处提供一个稳健的解决方案，它能够更灵活地使特定应用程序过滤掉服务器依赖的类。