默认情况下,OFBiz作为一个小型own应用程序的集合工作,每个应用程序都有自己的前端控制器。OFBiz网络应用程序通常依赖于许多公共模块。通常,特殊用途或热部署下的模块最终将取决于框架和下的几乎所有模块。有了嵌入式容器,所有库都进入catalina共享库类加载器,但是如果ofbiz需要部署在不同的容器中,就没有简单的方法。我认为唯一的选择是
鉴于此,the使用文件系统(、ofbiz.home、+ofbiz.home结果)加载了大部分资源。way应用程序真正需要以一种传统的servlet上下文的方式访问
我想知道我们是否可以使用前端控制器名称空间将多个we应用打包到一个单一的单一we应用程序中,这样war映射到单个根内容,比如/ ( root on tomcat)和/content、/webtools、/catalogE 253
、E 154
/ecommerceE 255
等仅仅是URL名称空间/子上下文,而不是单独的we应用程序。framework/common/webcommon/WEB-INF/controller.xml可以成为/ (ROOT tomcat)的根控制器,并为所有webapp提供checkLogin、autoLogin等,而无需每个控制器导入该controller.xml。
这将允许我们简单地使用部署模型,当我们想转移到其他容器时,比如weblogic、jboss等,我们最好构建一个单一的webapp,它的所有依赖项都整齐地打包到它的webapp/lib中,这样它就可以与同一个容器中的其他部署共存,而不影响它们的依赖关系和版本.
我相信struts有这种模块化的名称空间,其中可能有一个根级别的struts.xml (我们的例子controller.xml),每个模块都是一个有自己的模块/struts.xml或模块/struts-module.xml等的文件夹.
我个人认为这会有帮助..。我对缺点考虑得还不够。可能有很多吗?老实说我不知道。我对主题也没有给予足够的思考。显然,开发人员不希望看到代码的布局或组织方式发生任何变化。因此,在框架中对核心MVC代码进行一些小的更改后,我们可以使用一个简单的ant构建脚本来支持这种部署,该脚本将候选we应用程序划分为一个合并的单一we应用程序.
我希望看到关于这个想法的优点的辩论.如果我得到一些方向和投入,我甚至愿意投入一些时间来完成这项工作。
发布于 2013-11-03 07:08:24
发布于 2014-01-08 13:17:31
这是Apache OFBiz架构的一个困难部分。使用EAR文件工作正常,但是EAR文件中的共享类路径资源是特定于应用服务器的,您必须部署在一个支持EAR文件的容器中,从而限制选择。
其中一个限制是controller.xml文件中请求的平面命名空间,您所描述的是处理这个问题的最佳方法(为每个OFBiz组件应用程序使用不同的ControlServlet挂载点)。这样做可能需要对URL编写进行一些代码更改( @ofbizUrl FTL标记和其他地方使用的底层代码)。还需要做一些工作才能编写ant目标或其他东西来构建WAR文件,从各种组件(或仅仅是所需的组件)中提取所有的WAR应用程序,编写一个组合的web.xml文件等等。
这对于OFBiz来说是一个公认的问题,对大多数部署来说不是一个问题,但是与其他应用程序一起更难缩小或宿主。您可以通过OFBiz组件添加其他for应用程序,以便将它们托管在嵌入式servlet容器中,但我不认为这正是您要寻找的。
在OFBiz中进行这样的和许多类似的更改的问题之一是代码库大、用户群大,以及对这样的事情有不同意见的提交者组。由于这些和其他原因,很多改进OFBiz的想法在那里都无法轻易实现,这就是为什么我在2010年启动了项目。
Moqui使用单个WAR文件进行部署,并且可以有一个外部或嵌入式运行时目录,以便于部署在WAR托管服务(如AWS ElasticBeanstalk )上,也可以放到servlet容器(如Apache )上。WAR文件也是一个可执行的JAR文件,它使用嵌入式的温斯顿servlet容器进行更容易的开发和自动化测试。有关运行和部署Moqui的详细信息如下:
http://www.moqui.org/framework/docs/RunDeploy.html
顺便说一句,这是对OFBiz进行改进的数百个想法之一,这些改进使其成为Moqui和单独的带有数据模型和服务的项目()。有关这方面的一般资料如下:
https://stackoverflow.com/questions/19751025
复制