** 5月2日更新，包含案例研究：- 请查看此文章底部了解详情 ** 我相信大多数阅读此博客的读者都看到了昨天发布的 SpringSource 应用平台公告。如果没有，请务必查看 Rob 的博客文章，其中描述了一些动机、编程模型和路线图。

这里有一些常见问题，我想在此文章中直接解答。之后，我将描述另外两个令人兴奋的公告，它们补充了 SpringSource 应用平台本身，但昨天并没有成为头条新闻：…

经过数月的紧张编码，我很高兴地宣布 SpringSource 应用平台 1.0 的 Beta 版本发布。

在 2007 年初，我们开始讨论替代与企业 Java 成为同义词的单体式和重量级应用服务器的可能性。客户正在寻找一个轻量级、模块化且灵活的平台，以满足他们的开发和部署需求。

Spring 和 Tomcat 的组合证明，开发人员和运营人员可以在生产环境中成功使用轻量级平台。尽管这种组合取得了成功，但缺乏模块化和对非 Web 应用程序的明确支持限制了它的适用性和灵活性。

我们着手构建 SpringSource 应用平台来满足这些需求并消除这些限制。

平台的核心是动态模块内核 (DMK)。DMK 是一个基于 OSGi 的内核，它充分利用了 OSGi 平台的模块化和版本控制功能。DMK 基于 Equinox 并扩展其在配置和库管理方面的功能，并为平台提供核心功能。

为了保持最小的运行时占用空间，OSGi 包由 DMK 配置子系统按需安装。这允许将应用程序安装到正在运行的平台中，并从外部存储库满足其依赖关系。这不仅消除了手动安装所有应用程序依赖项的需要（这将非常繁琐），而且还将内存使用量保持在最低限度。

DMK 本身只需要最少的包即可运行，并使用 **配置文件** 配置以精确控制加载的其他模块集。例如，DMK 不需要 Tomcat，但默认平台配置文件包含 Tomcat 以允许部署 Web 应用程序。如果您想在没有 Tomcat 的情况下运行平台，您可以简单地编辑配置文件，它就不会被安装。（如果您尝试这样做 - 请记住，删除 Web 支持意味着 Web 模块将不再部署，因此请删除 pickup 目录的内容，以便平台在启动时不会尝试安装管理和启动画面应用程序。）安装了管理控制台的默认平台配置仅占用 15MB 的内存。

我一直对企业 Java 感到沮丧的一点是，应用程序通常被塞进人为设计的孤岛中，而且缺乏对不同应用程序类型的明确支持。考虑一个在线商店的应用程序。此应用程序具有 Web 前端、消息驱动的订单处理模块、批处理驱动的库存重新排序模块和 B2B Web 服务模块。如今，许多这样的应用程序将打包为 WAR 或 EAR，并且模块看起来非常相似，对模块类型差异的支持很少。有趣的是，许多人会将其称为 Web 应用程序，而不是具有 Web 模块的应用程序。

在 SpringSource 应用平台中，应用程序是模块化的，每个模块都有一个 **特性** 来描述它是什么类型的模块：Web、批处理、Web 服务等。平台以特定于特性的方式部署每个特性的模块。例如，Web 模块在 Tomcat 中使用 Web 上下文进行配置。应用程序中的每个模块都可以独立于其他模块进行更新，同时保留作为更大应用程序一部分的身份。无论您构建的是哪种类型的应用程序，编程模型仍然是标准的 Spring 和 Spring DM。

在 1.0 平台版本中，我们支持 **Web** 和 **Bundle** 特性，这使您可以构建复杂的 Web 应用程序。以后的版本将支持更多特性，详情将在后面介绍。

构建应用程序

平台支持三种形式的应用程序打包

1. Java EE WAR
2. 原始 OSGi 包
3. 平台存档 (PAR)

平台直接支持标准 WAR 文件。在部署时，WAR 文件将转换为 OSGi 包并安装到 Tomcat 中。所有标准 WAR 契约都将得到遵守，并且您现有的 WAR 文件应该可以直接部署而无需更改。

任何符合 OSGi 规范的包都可以直接部署到平台中，并且可以充分利用对 Import-Package 和 Require-Bundle 引用的任何依赖项的即时配置。

PAR 格式是为平台打包和部署应用程序的推荐方法。PAR 只是将 OSGi 包（模块）一起分组到标准 JAR 文件中，以及唯一标识应用程序的名称和版本。PAR 文件将作为单个单元部署到平台中。平台将从 PAR 中提取所有模块并安装它们。第三方依赖项将根据需要即时安装。

与直接将包部署到平台相比，PAR 格式具有三个主要优点。首先，它更容易。一个中等规模的企业应用程序可能包含 12 个以上的包 - 手动部署这些包将过于繁琐。其次，PAR 文件围绕应用程序中的所有包形成了一个明确的范围，这可以防止使用重叠类型或服务的应用程序相互冲突。此范围还被一些高级功能（如加载时编织）用于确保一个应用程序的编织不会干扰另一个应用程序的编织。最后，PAR 形成一个逻辑分组，用于定义哪些模块是应用程序的一部分以及应用程序具有哪些第三方依赖项。管理工具使用此分组来提供应用程序的详细视图。一个典型的 PAR 应用程序如下所示

应用程序中模块之间的依赖关系通常使用 Import-Package 和 Export-Package 来表示。对第三方库的依赖关系可以用相同的方式表示，但对于许多库来说，这可能会容易出错且耗时。当使用 Hibernate 等库时，您通常需要导入比您最初预期的更多包。为了解决这个问题，您可以使用 Require-Bundle，但这有一些语义上的粗糙边缘，例如分割包，其中逻辑包被拆分为两个或多个类加载器，从而导致运行时问题。平台引入了两种引用第三方依赖关系的新机制：Import-Bundle 和 Import-Libary。Import-Bundle 与 Require-Bundle 类似，但它可以防止分割包以及 Require-Bundle 的其他问题。Import-Library 提供了一种机制来引用由一组包导出的所有包，例如 Spring 框架中的所有包，在一个声明中

Bundle-SymbolicName: com.myapp.dao.jdbc
Bundle-Version: 1.0.0
Import-Bundle: org.apache.commons.dbcp;version="1.2.2.osgi"
Import-Library: org.springframework.spring;version="2.5.4.A"

这里我有一个模块包，它依赖于 Commons DBCP 包和 Spring 框架库。Spring 框架库包含在您的应用程序中使用 Spring 所需的所有包。

Import-Library 和 Import-Bundle 在底层扩展为 Import-Package，因此与标准 OSGi 语义一致。

平台了解模块的特性，并由此可以推断如何配置模块的执行环境。在部署 Web 模块时，将自动创建典型 Spring MVC 应用程序所需的所有 servlet 基础结构，从而无需跨应用程序重新创建此样板代码。在 1.0 正式版中，将向 Web 模块特性添加更多智能，以支持 Spring Web Flow 等其他技术。

无论您选择哪种打包格式，编程模型都只是 Spring 框架和 Spring 动态模块，其他 Spring 产品组合产品都运行在其之上。

可维护性

可维护性是整个工程团队高度重视的一个关键因素。我们花费了大量时间来仔细斟酌日志消息的格式和堆栈跟踪的大小，以确保您能够尽可能轻松地诊断应用程序问题。每当我们发现一项重复且耗时的任务时，我们都会寻找自动化或完全移除它的方法。

为了帮助诊断问题，平台在日志消息和跟踪消息之间进行了严格的区分。日志消息旨在供最终用户使用，让您可以访问最重要的故障信息，而无需浏览数 GB 的跟踪内容。所有应用程序故障都会显示在日志输出中并进行编码——这些代码可作为便捷的方式来访问知识库或支持内容。为了理解这为什么如此有用，请考虑以下平台启动输出

[2008-04-29 12:12:01.124] main                     <SPKB0001I> Platform starting.
[2008-04-29 12:12:04.037] main                     <SPKE0000I> Boot subsystems installed.
[2008-04-29 12:12:06.013] main                     <SPKE0001I> Base subsystems installed.
[2008-04-29 12:12:07.396] platform-dm-1            <SPPM0000I> Installing profile 'web'.
[2008-04-29 12:12:07.674] platform-dm…

自从 Spring Dynamic Modules 的第一个里程碑以来，关于在 OSGi 中运行 Web 应用的请求就开始涌现。这可能是最受请求的功能之一，毫不奇怪，一旦 1.0 正式版发布，Web 支持就成为 1.1 分支的主要焦点。我很高兴地报告，正如 刚刚发布的 M2 版本中，正如 Juergen 所暗示的那样，Spring-DM 不仅支持普通 WAR 文件（自 1.1.0 M1 起可用），还支持在 OSGi 内运行 Spring-MVC 应用程序。在本篇文章中，我想简要讨论典型的 OSGi Web 场景和 Spring-DM 的方法。但首先，

为什么要在 OSGi 中部署 WAR 文件？

为什么 OSGi 中的 Web 应用程序存在问题？

……

昨天，我写了一篇博客文章，讨论了Spring 如何帮助最大限度地提高应用程序的可移植性。即使可移植性问题多年来一直是企业 Java 领域的一个持续性话题，这篇博客文章也很及时。甲骨文宣布其以 67 亿美元收购 BEA Systems 的交易已完成。两家公司的产品组合之间存在大量重叠，因此这必然会给 WebLogic 和 OC4J 的客户群带来不确定性。WebLogic 和 OC4J 都可能属于“J2EE 服务器”类别，但它们是截然不同的产品，具有截然不同的特性。

由于许多企业……

可移植性是 Spring 宇宙中的一个关键因素。我们相信框架级别的可移植性：应用程序组件是针对特定框架（或框架生成）编写的，例如 Spring 2.5；然后，框架负责适应任何底层托管环境。但是，特定的应用程序框架位于托管环境之上，并且与托管环境不同。只要环境的基本功能足够，就可以将全新的框架版本部署到托管平台的已建立的版本上。这种方法……

昨天，我在德国威斯巴登的 JAX 大会 上发表了开幕主题演讲。JAX 是欧洲最大的 Java 大会之一，共有 2000 多名与会者。主题是*企业 Java 的未来*，我扩展了我最近关于预测的博客文章中的主题，更详细地介绍了Java EE 6 的意义和应用程序服务器的未来。
我已经上传了幻灯片，其中包括对企业 Java 演变中一个有趣时期的 8 项预测。这是我第一次在同一个演示文稿中提到约瑟夫·斯大林、莫妮卡·莱温斯基和蒙提·派森。
……

Spring Security 2.0 已发布。这是 Spring 产品组合向前迈出的重要一步。Spring (Acegi) Security 已经是 Java 平台上使用最广泛的企业安全框架，在 SourceForge 上的下载量超过 250,000 次，每次发布的下载量超过 20,000 次。通过使其使用起来更加简单，此版本无疑会将采用率提升到一个新的水平。

我对这个版本感到特别高兴，原因如下：

• 这对 Spring 社区来说是一件好事。它使用起来（非常）简单，而且功能更强大。它使更多用户能够使用功能最强大的企业 Java 安全解决方案，几乎消除了采用的障碍。请参阅此教程，了解它使保护典型 Web 应用程序变得多么容易。XML bean 定义的激增已成为过去。
• 它是 Spring 2.x 工作的延续，通过应用自定义 XML 命名空间的功能来实现积极的默认设置，同时仍然允许进行自定义。
• 与 Spring 2.5 一样，它体现了当前 Spring 产品组合中对减少对 XML 需求的趋势。
• 它是 SpringSource 业务模式价值的证明。我们的收入模式使我们能够比以往任何时候都更多地投资于创建开源软件。如果没有能够同时聘用 Acegi/Spring Security 创建者 Ben Alex 和另一位主要贡献者 Luke Taylor，那么这个版本要么不会出现，要么规模会小得多。
• 这对仙女王国来说是件好事。

Acegi/Spring Security 创建者 Ben Alex 和 Luke Taylor 做得很棒。Ben 将在下个月的 Java One 大会上谈论 Spring Security。如果……

Spring Security 2.0.0 现已可用。

下载 | 变更日志 | 公告 | 网站

经过近两年的开发，Spring Security 2.0.0 现已可以下载。这个重要的全新版本取代了 Acegi Security，成为 Spring 应用程序的官方安全模块。它提供了大大简化的配置，以及无数其他新功能，包括 OpenID、NTLM、JSR 250 注解、AspectJ 切点支持、域 ACL 增强、RESTful URI 授权、组、分层角色、用户管理 API、数据库支持的“记住我”功能、portlet 身份验证、其他语言、Web Flow 2.0 支持、Spring IDE 可视化和自动完成、通过 Spring Web Services 1.5 增强 WSS 支持等等。

尊敬的 Spring 社区：

我们很高兴地宣布 Spring Web Flow 2.0.0.RC1 现已可用。下载 | 文档

2.0.0.RC1 引入了几个新功能，并修复了针对先前里程碑版本报告的所有已知问题。

我们建议您从以前的 Web Flow 2 里程碑版本升级到 2.0.0.RC1。我们还建议 Web Flow 1 用户现在开始评估升级到 Web Flow 2，因为 RC1 引入了全面的 2.0 版文档，以及一个用于自动将 1.0 版流程转换为 2.0 版语法的工具。

开始使用 Web Flow 2 的最佳方法是评估分发版中包含的参考应用程序，并补充参考指南。Spring Web Flow 2 需要 Spring Framework 2.5.3 和 Java 1.4 或更高版本。

在下面的 2.0.0 RC1 版本中查找新增内容

2.0.0.RC1 新增内容

• 引入了 Web Flow 2 参考指南，提供 PDF 和 HTML 格式。新的指南采用“快速参考”风格编写，包含可运行的代码示例。在线阅读，或下载可打印的PDF。

• 增加了对从 Web Flow 1 升级到 2 的支持。此分发版中包含一个 *WebFlowUpgrader* 工具，能够将流程从 1.0 版语法转换为 2.0 版语法。有关如何使用此工具的说明，请参阅参考指南。

• 增加了对流程定义继承的支持。使用此功能，流程可以扩展一个或多个流程。流程状态也可以扩展另一个状态。此功能用于促进在共享公共结构的流程和状态之间进行重用。

• 新增Spring Portlet MVC支持。请参阅参考指南的Portlet部分以及booking-mvc-portlet和booking-faces-portlet示例应用程序。

• 正式推出新的“Spring Javascript”模块，包含在spring-js-2.0.0.RC1.jar中。此模块提供了一个Javascript抽象框架，用于以一致的方式应用客户端行为，例如表单验证和Ajax。它还捆绑了一个ResourceServlet，用于从jar文件中提供Javascript和CSS（也包含CSS框架）。此框架构建的基础默认UI工具包是Dojo 1。Spring的JSF集成模块（称为“Spring Faces”）基于spring-js，提供了一个轻量级的JSF组件库，用于表单验证和Ajax。

• 添加了Spring Faces与RichFaces JSF组件库的集成。Rich Faces可以与Spring Faces组件库一起使用，也可以独立使用。一个演示此集成的示例应用程序可在我们的JIRA系统中找到。

• 添加了一个“jsf-booking”参考应用程序，该应用程序比较了传统的JSF Web应用程序和使用JSF作为UI组件模型的Spring Web应用程序。将jsf-booking与booking-faces进行比较，以了解架构方法和实现方面的差异。对于有兴趣了解Spring的JSF开发人员来说，这种比较尤为重要。

• 增加了对Spring MVC自动模型绑定和验证的支持。此支持提供了一种简洁的替代方法，无需手动进行FormAction setupForm和bindAndValidate调用。此支持还允许在应用程序范围内注册数据输入Formatter，在许多情况下，无需逐个视图手动注册PropertyEditors。提供了对抑制数据绑定的支持，例如取消按钮点击事件。提供了根据约定调用验证器的支持。请参阅booking-mvc示例。

• 引入了视图作用域。视图作用域在视图状态进入时分配，在视图状态退出时销毁。此作用域对于在多次Ajax请求中更新特定于一个视图的模型非常有用。它也是用于管理JSF组件状态的作用域。

• 添加了对流程消息包的支持。在您需要支持的区域设置的流程工作目录中创建一个messages.properties文件即可。

• 引入了可配置的视图状态历史策略。视图状态可以保留其历史记录以支持回溯，丢弃其历史记录以防止回溯，并使所有先前历史记录失效以在不可逆转点之后禁止回溯。请参阅视图状态元素上的新“history”属性。

• 改进了流程执行快照过程。这些改进在回发时捕获视图状态表单值，以支持在回溯时恢复这些值。这在使用浏览器后退按钮返回时保留了存储在流程作用域中的数据编辑。

• 简化了流程执行测试，允许您跳转到任何状态以开始测试用例。请参阅booking-mvc和booking-faces以了解流程测试用例的示例。
  

• 改进了booking-mvc作为参考应用程序，展示了@Controllers与Flows结合使用。新的FlowHandler概念在Controllers和Flows之间提供了一个清晰的桥梁，允许这两种类型的处理器以结构化的方式进行交互。还改进了参考应用程序Spring配置的组织，以说明最佳实践。