Hibernate бесполезен и наносит урон разработчикам.
Не поддавайтесь искушению поместить файлы jar в «общую» папку вашего контейнера. Лучше оставить файлы jar там, где они сейчас находятся. Использование общей папки сейчас может показаться хорошей идеей, но в будущем вам может потребоваться развернуть приложение, для которого требуется общая библиотека, но другой версии.
При этом у меня нет опыта работы с WebLogic. В Tomcat есть общая папка с общими для всех развернутых приложений библиотеками. Использовать это - не лучшая идея. Если WebLogic можно настроить для использования общей папки для набора приложений (а не для всех развернутых приложений), вы можете пойти на это.
Поместите все общие файлы jar в общую папку \ lib в weblogic. common \ lib доступен для всех развернутых приложений.
Вы хотите это сделать? Если вы не застряли в пространстве для развертывания, я бы (возможно) посоветовал этого не делать.
Почему? На данный момент у вас есть 4 решения, работающих с этими библиотеками. Если вам нужно обновить одну из библиотек (например, если вы обнаружите ошибку или вам потребуется новая функция), вам придется протестировать совместимость и функциональность для всех 4 решений. Если каждое решение имеет свой собственный набор библиотек, то они изолированы, и вам не нужно перемещать все 4.
Обратите внимание, что все это зависит от того, насколько легко регрессионное тестирование ваших решений. Вы можете найти это несложно, и в этом случае возможно использование одного и того же набора библиотек.
Ну, во-первых, вы можете поместить свои библиотеки в одно и то же место и сделать так, чтобы процесс сборки импортировал нужные.
При развертывании нового Weblogic 10 есть папка lib в каждый домен, где можно разместить общие библиотеки. я не думаю, что это возможно до Weblogic 10
Сейчас я использую другой подход.
Каждый раз, локальная рабочая копия обновляется, внешние - до, поэтому вам просто нужно зафиксировать в центральной папке, и она автоматически распространяется по всем проектам.
Don't do that.
The whole idea of WAR files is that they are self-contained units. This makes deployment so much easier.
In addition to the possible version conflicts that others have pointed out, putting jar files in /shared can have very nested consequences for class visibility. They will be on a separate classloader, and be unable to see the classes in the WAR file. If you use libraries that rely on Class.forName() to work (and there are plenty), this could get very painful.
If you really, really cannot afford the extra disk space and memory look at OSGi or Spring DM. They have solved this problem, but at the price of increased complexity.
Вы можете поместить банки в их собственный ушной файл и развернуть его как общую библиотеку.
Вы также можете положить войны в ухо и добавить общие jar-файлы в APP-INF / lib. Это расширение J2EE Weblogic, поэтому оно не будет работать на других серверах.