取得领先
VMware 提供培训和认证来加速您的进步。
了解更多Web 应用程序和 OSGi
自从 Spring Dynamic Modules 的第一个里程碑版本以来，就不断有关于在 OSGi 中运行 Web 应用程序的请求。 这可能是最受请求的功能之一，毫不奇怪，一旦 1.0 最终版发布，Web 支持就成为 1.1 分支的主要关注点。 我很高兴地报告，随着刚刚发布的 M2，正如 Juergen 已经暗示的那样，Spring-DM 不仅支持 vanilla war 文件（自 1.1.0 M1 起可用），还支持在 OSGi 中运行的 Spring-MVC 应用程序。 在这篇文章中，我想简要讨论典型的 OSGi Web 场景和 Spring-DM 的方法。 但首先，
为什么要在 OSGi 中部署 WAR 文件？
简单的问题：OSGi *原生*提供版本控制、包连接和热重载。 想象一下在你的应用程序中利用这些特性：你可以停止嵌入库在WEB-INF/lib并开始在你的 Web 应用程序之间共享它们，避免 taglibs 的重复（同时保持多个版本运行），并在运行时只更新应用程序的某些部分。 这特别有用，因为 Web 应用程序往往是分层的，因此在其生命周期内会受到大量更改。为什么 OSGi 中的 Web 应用程序存在问题？
Servlet 规范围绕 *Web 容器* 的概念展开：Web 组件的运行时环境，提供标准服务，如生命周期管理（对象创建和销毁，线程分配）、并发、HTTP 请求处理等。 另一方面，OSGi 平台也充当一个托管环境，具有其服务注册表、包连接和版本控制（仅举几个例子）。 为了解决这个问题，OSGi 委员会设计了组合规范的一部分，即 Http Service。顺便说一句，当处理两个托管环境时，人们面临一个有趣的问题：使用什么部署模型？ 也就是说，哪个是引导平台，哪个是嵌入的？ 在我们的例子中，可以部署 OSGi 平台作为一个 WAR 文件，或者在 OSGi 平台内部部署 Web 容器（以某种服务形式）。 不过，更多关于这方面的内容将在以后的文章中介绍。
这个可选服务提供了一个简单的 API 用于注册Servlet和映射到传入 HTTP 请求的静态资源。 为了有一个Servlet在 OSGi 内部提供服务的实例，必须以编程方式创建Servlet实例并通过上述 API 注册它。 此外，Http 服务仅支持Servlet2.1 规范，这可能非常不方便，因为过滤器和监听器（今天几乎所有 Web 框架都在使用）都不可用。 目前可用的（据我所知）在 OSGi 中运行 Web 应用程序的大多数（如果不是全部）解决方案都依赖于 Http Service 的功能。 一些人使用以下技术之一（据我所知）解决了上述问题
- 通过强加新的或翻译现有的声明式方法（例如web.xml）到对 Http Service 的调用中，从而消除对代码的需求
- 提供Servlet通过构建在 2.1 API 之上（例如，过滤器可以通过装饰一个Servlet实例）或通过扩展标准 API，提供 2.1+ 功能
直接与 Web 容器集成
在 Spring-DM 中，OSGi 和容器空间被桥接：WAR 文件像往常一样部署到 Web 容器，使用 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 将 bundles **原生** 部署到所选的 Web 容器（目前开箱即支持 Apache Tomcat 5.5.x/6.0.x 和 Jetty 6.1.x+）。 这意味着 Web 容器实例化和管理 Web 应用程序，因此容器支持的几乎所有内容都可供 OSGi bundles 使用。
虽然 1.1 尚未最终发布，但我鼓励您尝试一下 M2。 API 几乎是稳定的，并且新功能已经记录（随着我们接近 GA 版本，会有更多内容） - 如果您需要帮助，请查看 Spring-DM 论坛（是的，我们终于有了一个）和邮件列表。 此外，如果您恰好在 JavaOne，请到 SpringSource 展位，您将从源头获得答案。