4

默认情况下，OFBiz 作为小型 Web 应用程序的集合，每个应用程序都有自己的前端控制器。OFBiz webapps 通常依赖于很多通用模块。通常，特殊用途或热部署下的模块最终将取决于框架和应用程序下的几乎所有模块......使用嵌入式容器，所有库都进入 catalina 共享库类加载器，但如果 ofbiz 需要部署在一个不同的容器，根本没有简单的方法。我认为唯一的选择是

  1. 将 ofbiz 打包为带有EAR/lib或EAR/APP-INF/lib的 EAR ，以便所有 webapps 都可以访问一组通用的 EAR 级类路径资源。通常是每个模块的config、lib和所有重要的ofbiz-$module。罐
  2. 每个 webapp 都将每个所需的 jar 打包到自己的WEB-INF/lib中 .. 过多的重复，并且在某种意义上也增加了文件系统的占用空间
  3. 使用应用程序系统类路径代替 catalina shared.lib 文件夹——这意味着 JVM 必须专用于 ofbiz，否则它的 jar 会干扰其他同级部署，甚至可能干扰容器本身，通常是 XML、XSL、 STAX api等。

鉴于 ofbiz 使用文件系统（ofbiz.home + component://）resulution加载大部分资源。webapp 真正需要在传统的 servlet 上下文中访问的是

  • 控制器.xml
  • 类路径资源 - 跨越 shared.lib 中的各种 ofbiz-$module.jar。通常，每个模块的config、lib和所有重要的biz-$module.jar
  • 为各种模块导入（component://）webapp 资源，如其他 controller.xml。最重要的是framework/common/webcommon/WEB-INF/controller.xml提供样板安全实现，如 checkLogin 和 autoLogin....

我想知道我们是否可以使用前端控制器命名空间以某种方式将多个 web 应用程序打包到一个单一的整体 web 应用程序中，以便战争映射到单个根内容，例如说/（tomcat 上的ROOT ）和/content、/webtools、/catalog、/ ecommerce等. 只是 URL 命名空间/子上下文，而不是单独的 webapps。 framework/common/webcommon/WEB-INF/controller.xml可以成为 /（tomcat 中的 ROOT）的根控制器，并为所有 webapps 提供 checkLogin、autoLogin 等，而无需每个控制器都必须导入该 controller.xml

当我们想要迁移到其他容器（例如 weblogic、jboss 等）时，这将允许我们简单地部署模型，在这些容器中，我们最好构建一个单一的 webapp，并将其所有依赖项整齐地打包到其WEB-INF/lib中，例如它可以与同一个容器中的其他部署共存，而不会干扰它们的依赖关系和它们的版本......

我相信 struts 有这种模块化命名空间，其中可能有根级别 struts.xml（我们的案例 controller.xml），每个模块都是一个文件夹，有自己的 module/struts.xml 或 module/struts-module.xml 等...

我个人觉得这会有所帮助.. 我对缺点的考虑还不够。可能有很多？我真的不知道。我也没有对主题给予足够的考虑..开发人员显然不希望看到代码布局或组织方式的任何变化..所以有一些小问题？:) 框架中核心 MVC 代码的更改，我们可能会使用一个简单的 ant 构建脚本来支持这种部署，该脚本将候选 webapps 分阶段为一个合并的整体 webapp...

我希望看到关于这个想法的优点的辩论......如果我得到一些方向和投入，我什至愿意投入一些时间来完成这项工作......

4

2 回答 2

3

这是 Apache OFBiz 架构的一个困难部分。使用 EAR 文件可以正常工作，但 EAR 文件中的共享类路径资源是特定于应用程序服务器的，并且您必须部署在支持 EAR 文件的容器中，这限制了选择。

其中一个限制是 controller.xml 文件中请求的平面命名空间，您所描述的将是处理该问题的最佳方法（为每个 OFBiz 组件应用程序使用不同的 ControlServlet 安装点）。这样做可能需要对 URL 编写进行一些代码更改（@ofbizUrl FTL 标记和其他地方使用的底层代码）。它还需要一些工作来编写一个 ant 目标或构建 WAR 文件的东西，从各种组件（或只是那些需要的组件）中提取所有 webapps，编写一个组合的 web.xml 文件，等等，等等。

这是 OFBiz 公认的问题，对于大多数部署来说不是问题，但确实使缩减或与其他应用程序一起托管变得更加困难。您可以通过 OFBiz 组件添加其他 webapps 以将它们托管在嵌入式 servlet 容器上，但我不认为这是您要寻找的。

在 OFBiz 中进行此更改和许多类似更改的问题之一是庞大的代码库、庞大的用户群以及对此类事情有不同意见的较大的提交者群体。由于这些和其他原因，很多改进 OFBiz 的想法在那里无法轻易实现，这就是我在 2010 年启动 Moqui 框架项目的原因。

Moqui 使用单个 WAR 文件进行部署，并且可以具有外部或嵌入式运行时目录，以便轻松部署在 WAR 托管服务（例如 AWS ElasticBeanstalk）上，以及放入 servlet 容器（例如 Apache Tomcat）。WAR 文件也是使用嵌入式 Winstone servlet 容器的可执行 JAR 文件，以便于开发和自动化测试。这里有关于运行和部署 Moqui 的详细信息：

http://www.moqui.org/framework/docs/RunDeploy.html

顺便说一句，这是对 OFBiz 进行改进的数百个想法之一，这些想法使其成为 Moqui 框架和具有数据模型和服务的单独项目（Mantle Business Artifacts）。这里有关于它的一般信息：

http://www.moqui.org/

于 2014-01-08T21:17:31.410 回答
3

您是否考虑过使用 chef 来部署 Ofbiz？

我写了以下食谱来演示它是如何工作的：

于 2013-11-03T15:08:24.113 回答