Eclipse Java утилита проекта и несколько веб-приложений

Question

Если я создам служебный проект и несколько динамических веб-проектов в Eclipse и настрою его так, чтобы динамические веб-проекты зависели от служебного проекта, я предполагаю, что мне придется повторно развертывать все динамические веб-проекты на сервере, еслив какой-то момент я делаю улучшения в служебном проекте.Если я правильно понимаю, установка зависимостей упакует служебные классы в папку каждого динамического веб-проекта WEB-INF / lib, создавая несколько копий служебной программы jar / classes.

Но есть ли способ получить одну копиюутилиты jar / classes, развернутые на моем сервере и разделенные между моими приложениями?Я работаю в компании, в которой есть процедура Управления конфигурациями (бюрократизм, бумажная работа, без добавленной стоимости), поэтому я бы не хотел повторно развертывать ВСЕ мои приложения и проходить процесс CM каждый раз, когда я вносил изменения в свой служебный класс.Я хотел бы иметь возможность смонтировать утилиту, а затем запустить все мои приложения, используя обновленный проект утилиты.

Answer 1

В Eclipse, ссылка на проект утилиты в пути сборки, но не экспортируйте его как зависимость модуля Java EE. Чтобы поделиться им со всеми веб-приложениями на одном сервере, просто укажите путь к классу сервера. Неясно, какой из них вы используете, поэтому я не могу дать более подробный ответ. В случае Tomcat это папка /lib. В качестве альтернативы вы также можете добавить его путь к общему пути к классам Tomcat, как определено в catalina.properties. После обновления достаточно просто перезапустить / переустановить, чтобы веб-приложение (и) выбрало изменения. Другие сервлетконтейнеры / приложения предлагают аналогичные возможности. См. Также Tomcat Classloader HOW-TO .

Answer 2

Прежде всего, с точки зрения управления, вы должны знать, что все используют эту банку и на что повлияет ее изменение.

Если вы можете повлиять на несколько проектов, то, возможно, было бы лучше на самом деле упаковать его с приложением, поскольку вы можете контролировать, когда вы «обновляете» до последней версии jar для каждого проекта / приложения.

Если вы хотите обновить их все одновременно без их повторного развертывания, то лучше всего поместить файл в место, доступное для вашего сервера приложений (каталог общей библиотеки).

Затем настройте ваше приложение, чтобы добавить этот jar в путь к классам. Теперь, если вы обновите банку, она затронет их всех сразу.

Вам все еще может потребоваться отменить приложения или сервер, чтобы изменения вступили в силу (зависит от сервера).

Answer 3

Прошло некоторое время с тех пор, как это было опубликовано, поэтому, вероятно, спорный вопрос, но может помочь другим.

Другим вариантом наличия единой общей библиотеки, используемой отдельными приложениями более высокого уровня, является система управления версиями в служебной библиотеке.

По сути, вы публикуете определенный «уровень обслуживания» API из библиотеки утилит под некоторым идентификатором версии, например, с увеличенным целым числом (независимо от базовой базы кода библиотеки утилит):

• Уровень API: 1
• API ID: UTIL_API_20110630_1.0.1

Затем в служебной библиотеке вы обрабатываете промежуточную поддержку «устаревших» API ... просто помещая «старые» интерфейсы библиотеки в новую библиотеку… либо в тот же jar, либо в «дочернюю» jar. (Utility.jar переназначает вызовы child.jar).

Таким образом, приложение устанавливает Уровень API , который оно желает. Таким образом, приложения только когда-либо видят основной «Utility.jar» и получают к нему доступ через требуемый уровень API, даже если внутренняя реализация может изменяться и развиваться.

App X, Y, Z
Util.jar
--> Util_1.0.1.jar  (API Level: 1)
--> Util_1.0.3.jar  (API Level: 1)
--> Util_1.2.7.jar  (API Level: 1)
--> ...
--> Util_2.0.1.jar  (API Level: 2)

Еще одним преимуществом является то, что, если «App X» больше не находится в активной разработке, оно все еще имеет тот же API, функциональность и поведение, которые всегда были известны. Между тем библиотека утилит и Приложения Y и Z могут продолжать работать без изменений.

Немного больше работы по созданию проходных пакетов для первого из последующих выпусков. (И сильно зависит от природы служебной библиотеки.) Но затем она становится быстрой копией / вставкой, изменяет уровень API, переименовывает, и вы уже в пути.