我最近一直在研究OSGi,并认为它对于模块化Java应用程序来说是一个非常好的主意.
但是,我想知道OSGi如何在Web应用程序中工作,在那里你不仅要担心代码 - 还有HTML,图像,CSS等等.
在工作中,我们正在构建一个具有多个"标签"的应用程序,每个标签都是应用程序的一部分.我认为这可以从采用OSGi方法中获益 - 但是我真的不确定什么是处理所有常用Web应用程序资源的最佳方法.
我不确定它是否有任何区别,但我们正在使用JSF和IceFaces(这会增加另一层问题,因为你有导航规则,你必须在web.xml中指定所有面部配置文件...... doh! )
编辑:根据这个线程,faces-config.xml文件可以从JAR文件加载 - 所以实际上可以包含多个faces-config.xml文件而不修改web.xml,只要你分成JAR文件.
任何建议将不胜感激 :-)
你认为这里有协同作用是非常正确的,我们有一个模块化的网络应用程序,其中应用程序本身是从独立组件(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本身,使其可组合,可重用,动态.
这些是系统中的组件:
1个中心包,负责使用OSGi桥接Spring MVC,特别是它使用Bernd Kolb的代码,允许您将OSDi注册为Spring DispatcherServlet作为servlet.
1个自定义URL映射器,它注入到DispatcherServlet中,并提供传入HTTP请求到正确控制器的映射.
1个基于Sitemesh的中心装饰器JSP,用于定义站点的全局布局,以及我们希望作为默认值提供的中央CSS和Javascript库.
每个想要向我们的Web UI提供页面的包必须将一个或多个控制器作为OSGi服务发布,并确保使用OSGi HTTPService 注册自己的servlet和自己的资源(CSS,JSP,图像等).注册是通过HTTPService完成的,关键方法是:
httpService.registerResources()和httpService.registerServlet()
当web ui贡献包激活并发布其控制器时,它们将由我们的中央web ui包自动获取,前面提到的自定义URL Mapper收集这些Controller服务并保存到Controller实例的URL的最新映射.
然后当HTTP请求进入某个URL时,它会找到关联的控制器并在那里调度请求.
Controller完成其业务,然后返回应呈现的任何数据和视图的名称(在我们的示例中为JSP).这个JSP位于Controller的包中,可以由中央web ui bundle完全访问和呈现,因为我们使用HTTPService注册了资源位置.然后,我们的中心视图解析器将此JSP与我们的中心Sitemesh装饰器合并,并将生成的HTML吐出到客户端.
知道这是相当高的水平,但没有提供完整的实施,很难完全解释.
我们的关键学习点是看看Bernd Kolb将他的示例JPetstore转换为OSGi并使用该信息来设计我们自己的架构.
恕我直言,目前有太多的炒作,并专注于使OSGi以某种方式嵌入在传统的基于Java EE的应用程序中,并且很少考虑实际使用OSGi成语及其出色的组件模型来真正允许组件化Web应用程序的设计.