我最近一直在研究OSGi，并认为它对于模块化Java应用程序来说是一个非常好的主意。
但是，我想知道OSGi如何在Web应用程序中工作，在那里您不仅要担心代码 - 还有HTML，图像，CSS之类的东西。
在工作中，我们正在构建一个具有多个“选项卡”的应用程序，每个选项卡都是应用程序的一部分。我认为这可以从采用OSGi方法中受益 - 但是我真的不确定处理所有常用Web应用程序资源的最佳方式是什么。
我不确定它是否有任何区别，但是我们正在使用JSF和IceFaces（这增加了另一层问题，因为您有导航规则，并且您必须在Web中指定所有面部配置文件.xml...哎呀！
编辑：根据这个线程，face-config.xml文件可以从JAR文件加载 - 所以实际上可以在不修改web.xml的情况下包含多个face-config.xml文件，只要你拆分成JAR文件。
任何建议将不胜感激：-）
你认为这里有协同作用是非常正确的，我们有一个模块化的Web应用程序，其中应用程序本身是从独立的组件（OSGi捆绑包）自动组装的，其中每个捆绑包都贡献自己的页面，资源，css和可选的javascript。
我们不使用JSF（这里的Spring MVC），所以我不能评论OSGi上下文中该框架增加的复杂性。
大多数框架或方法仍然遵循“旧”的思维方式：一个WAR文件代表你的webapp，然后是许多OSGi捆绑包和服务，但几乎没有一个关注GUI本身的模块化。
使用OSGi，要解决的第一个问题是：您的部署场景是什么，谁是主要容器？我的意思是，您可以在OSGi运行时上部署应用程序，并将其基础架构用于所有事情。或者，您可以在传统的应用程序服务器中嵌入OSGi运行时，然后您需要重用一些基础架构，特别是您想要使用AppServer的servlet引擎。
我们的设计目前基于OSGi作为容器，我们使用OSGi提供的HTTPService作为我们的servlet容器。我们正在考虑在外部 servlet 容器和 OSGi HTTPService 之间提供某种透明的桥梁，但这项工作正在进行中。
因此，目标不仅仅是通过OSGi为Web应用程序提供服务，而且还将OSGi的组件模型应用于Web UI本身，使其可组合，可重用，动态。
这些是系统中的组件：
每个想要为我们的Web UI贡献页面的捆绑包都必须将1个或多个控制器发布为OSGi服务，并确保向OSGi HTTPService注册自己的servlet和自己的资源（CSS，JSP，图像等）。注册是使用 HTTP 服务完成的，关键方法是：
httpService.registerResources（） 和 httpService.registerServlet（）
当 Web ui 贡献捆绑包激活并发布其控制器时，我们的中央 Web UI 捆绑包会自动选取它们，并且上述自定义 URL 映射器会收集这些控制器服务，并保持到控制器实例的 URL 的最新映射。
然后，当HTTP请求进入某个URL时，它会找到关联的控制器并在那里调度请求。
控制器执行其业务，然后返回应呈现的任何数据和视图的名称（在本例中为 JSP）。这个JSP位于控制器的捆绑包中，可以由中央Web ui捆绑包访问和呈现，因为我们去HTTPService注册了资源位置。然后，我们的中心视图解析器将此 JSP 与我们的中央 Sitemesh 装饰器合并，并将生成的 HTML 输出给客户端。
要知道这是相当高的水平，但如果没有提供完整的实现，就很难完全解释。
我们的关键学习点是看看Bernd Kolb用他的JPetstore转换为OSGi的例子做了什么，并使用这些信息来设计我们自己的架构。
恕我直言，目前有太多的炒作和关注，以某种方式将OSGi嵌入到传统的基于Java EE的应用程序中，而很少考虑实际使用OSGi习语及其出色的组件模型来真正允许组件化Web应用程序的设计。
查看SpringSource dm Server - 一个完全根据OSGi和支持模块化Web应用程序构建的应用程序服务器。它提供免费，开源和商业版本。
您可以从部署一个标准的 WAR 文件开始，然后逐渐将应用程序分解为 OSGi 模块，或 OSGi 语言中的“捆绑包”。正如您对SpringSource所期望的那样，该服务器对Spring框架和相关Spring产品组合产品提供了出色的支持。
免责声明：我从事此产品的工作。
