自从 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-INF/lib下，并开始在你的 Web 应用之间共享它们，避免标签库重复（同时保持多个版本运行）并在运行时仅更新应用的某些部分。这在 Web 应用倾向于分层且在其生命周期中容易发生大量变化的情况下尤其有用。

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

Servlet 规范围绕Web 容器的概念展开：一个为 Web 组件提供标准服务的运行时环境，例如生命周期管理（对象创建和销毁、线程分配）、并发、HTTP 请求处理等等。另一方面，OSGi 平台也充当一个受管理的环境，拥有其服务注册表、包连接和版本控制（仅举几例）。为了解决这个问题，OSGi 委员会在规范汇编中设计了Http 服务。

顺便说一句，当处理两个受管理的环境时，会遇到一个有趣的问题：使用哪种部署模型？也就是哪个是引导平台，哪个是被嵌入的？在我们的例子中，可以将 OSGi 平台部署为 WAR 文件，或者将 Web 容器（以某种服务的形式）部署到 OSGi 平台内部。不过，关于这一点，我们将在以后的博文中详细介绍。

此可选服务提供了一个简单的 API，用于注册Servlet和静态资源，这些资源被映射到传入的 HTTP 请求。为了在 OSGi 内部Servlet服务请求，必须以编程方式创建Servlet实例并通过上述 API 注册它。此外，Http 服务仅支持Servlet2.1 规范，这可能很不方便，因为过滤器和监听器（当今几乎所有 Web 框架都使用）不可用。今天（据我所知）几乎所有（如果不是全部）可用于在 OSGi 中运行 Web 应用的解决方案都依赖于 Http 服务来实现其功能。有些解决方案使用以下技术之一来解决上述问题（据我所知）

• 通过强加新的或转换现有的声明式方法（例如web.xml）为 Http 服务调用来消除对代码的需求
• 通过构建 2.1 API 之上（例如，可以通过装饰一个Servlet实例来实现过滤器）或扩展标准 API 来提供Servlet2.1+ 功能

这两种方法都可以取得成功并取得很大进展，然而，在 Spring-DM 中，我们选择了一种不同的、独特的方法，即

直接与 Web 容器集成

在 Spring-DM 中，OSGi 和容器空间之间架起了桥梁：像往常一样部署到 Web 容器的 WAR 文件使用 OSGi 空间进行类路径和资源查找。这种方法的主要优点是，对于 OSGi 平台和 Web 容器来说，都没有发生重大变化——一切都“照常进行”。

使用 Spring-DM，可以获得

• 完整的 Servlet 2.4/2.5、JSP 2.0/2.1 规范支持
• 容器功能的可用性（阻塞与非阻塞 IO、线程池中分配的线程等等）
• 完全访问web.xml语法，无论是关于过滤器、监听器、映射声明、安全甚至 JNDI 引用。这在容器与 JTA 事务管理器或 JMS 队列集成的情况下尤其有用。请注意，Spring-DM 不执行解析（我们认为容器在这方面做得比我们好得多）
• 容器特定的配置文件（例如 Tomcat 的META-INF/context.xml)

所有这些以及更多功能都是可能的，因为 Spring-DM 将捆绑包原生部署到选择的 Web 容器（目前开箱即用支持 Apache Tomcat 5.5.x/6.0.x 和 Jetty 6.1.x+）。这意味着 Web 容器实例化和管理 Web 应用，因此容器支持的几乎所有内容都可用于 OSGi 捆绑包。

虽然 1.1 尚未最终确定，但我鼓励您尝试一下M2。 API 非常稳定，并且新功能已记录（随着我们接近 GA 版本，还会有更多内容发布）——如果您需要帮助，请查看 Spring-DM 论坛（是的，我们终于有了）和邮件列表。此外，如果您碰巧在 JavaOne，请访问 SpringSource 的展位，您将从源头获得答案。