OFBiz по умолчанию работает как набор небольших веб-приложений, каждое из которых имеет собственный фронт-контроллер. Веб-приложения OFBiz обычно зависят от множества общих модулей. Как правило, модули специального назначения или горячего развертывания в конечном итоге зависят практически от всех модулей в framework и приложениях... со встроенным контейнером все библиотеки переходят в загрузчик классов совместно используемой библиотеки Catalina, но если ofbiz необходимо развернуть в другом контейнере, простого способа просто не существует. единственные варианты я считаю
- package ofbiz как EAR с EAR/lib или EAR/APP-INF/lib, чтобы все веб-приложения имели доступ к общему набору ресурсов пути к классам на уровне EAR. Обычно config каждого модуля, lib и все важные файлы ofbiz-$module.jar.
- каждое веб-приложение упаковывает каждый из необходимых jar-файлов в свой собственный WEB-INF/lib... слишком много дублирования, а также в некотором смысле увеличивает объем файловой системы
- используйте путь к классу системы приложений вместо папки catalina shared.lib, что означает, что JVM должна быть выделена для ofbiz, поскольку в противном случае ее jar-файлы будут мешать другим одноуровневым развертываниям и, возможно, даже самому контейнеру, обычно таким вещам, как XML, XSL, STAX apis и т.д..
учитывая, что ofbiz загружает большинство ресурсов, используя файловую систему (ofbiz.home + component://). К чему веб-приложению действительно нужен доступ в обычном контексте сервлета, так это
- контроллер.xml
- ресурсы classpath — в различных файлах ofbiz-$module.jar в shared.lib. как правило, config, lib каждого модуля и все важные файлы ofbiz-$module.jar
- импортированные (component://) ресурсы веб-приложения, такие как другие controller.xml для различных модулей. наиболее важным является файл framework/common/webcommon/WEB-INF/controller.xml, который обеспечивает стандартную реализацию безопасности, такую как checkLogin и autoLogin....
Мне было интересно, можем ли мы каким-то образом упаковать несколько веб-приложений в одно монолитное веб-приложение, используя пространство имен переднего контроллера, чтобы война сопоставлялась с одним корневым содержимым, например, / (ROOT на tomcat ) и /content, /webtools, /catalog, /ecommerce и т. д. – это скорее просто пространства имен/подконтексты URL-адресов. чем отдельные веб-приложения. framework/common/webcommon/WEB-INF/controller.xml может стать корневым контроллером для / (ROOT в tomcat) и предоставить checkLogin, autoLogin и т. д. для всех веб-приложений без необходимости импорта каждым контроллером этого контроллера. XML
Это позволило бы нам просто использовать модель развертывания, когда мы хотели бы перейти к другим контейнерам, таким как, скажем, weblogic, jboss и др., где нам было бы лучше создать одно веб-приложение со всеми его зависимостями, аккуратно упакованными в его WEB-INF. /lib, чтобы он мог сосуществовать с другими развертываниями в одном контейнере, не мешая их зависимостям и их версиям...
Я полагаю, что у struts было такое модульное пространство имен, где мог быть struts.xml корневого уровня (в нашем случае controller.xml), и каждый модуль был бы папкой со своим собственным модулем /struts.xml или модулем /struts-module.xml и т. д. ...
я лично чувствую, что это было бы полезно .. я недостаточно думал о недостатках. их может быть много? я честно не знаю. Я также не уделял должного внимания темам. Разработчики явно не хотели бы видеть какие-либо изменения в способе размещения или организации кода.. Так что с некоторыми незначительными? :) изменений в основном коде MVC в фреймворке, мы могли бы потенциально поддержать этот тип развертывания, используя простой скрипт сборки ant, который превращает веб-приложения-кандидаты в объединенное монолитное веб-приложение...
я надеялся увидеть дебаты по достоинствам этой идеи... я даже был бы готов потратить некоторое время на выполнение этой работы, если бы я получил какое-то направление и вклад..
