Развертывание WAR несколько раз в Websphere с разными свойствами?

Question

У нас есть приложение Axis2, которое мы запускаем на сервере приложений websphere. Приложение упаковано в файл WAR. Нам нужно запустить две копии одной и той же WAR в одной и той же копии websphere, и каждая копия приложения должна загрузить свой файл свойств из файловой системы. Я ищу что-то, что можно установить из консоли управления websphere при развертывании приложения, которое видно приложению и может использоваться для изменения того, как приложение ищет его свойства.

В данный момент файл свойств хранится в WAR, поэтому мы создаем разные версии WAR для каждой среды. Вместо этого мы хотели бы использовать один файл WAR, не зависящий от среды, с внешним файлом свойств, хранящимся в файловой системе. У нас это работает. Однако у нас есть две среды разработки, размещенные в одной и той же копии веб-сферы. Поэтому нам нужно развернуть две копии одной и той же WAR на одном и том же сервере websphere, и каждый экземпляр должен загрузить свой файл свойств.

Одна вещь, которую мы попробовали, была проверка корневого контекста. При развертывании двух копий приложения каждая из них должна иметь разный корневой контекст (первая часть URL-адреса, используемого для доступа к приложению), а Axis2 ConfigurationContext включает функцию для чтения корневого контекста. К сожалению, когда приложение работает в WAS, оно получает представление Axis2 о корне контекста, который всегда является «axis2», а не о реальном корне контекста, который использует WAS.

РЕДАКТИРОВАТЬ: Чтобы уточнить, мы хотим загрузить файл свойств во время запуска приложения (во время ServiceLifecycle.startup () для тех из вас, кто знаком с Axis2). В этот момент фактический запрос веб-службы не обрабатывается, поэтому у нас нет проверяемого контекста сообщения.

Answer 1

Мы нашли функцию websphere под названием разделяемые библиотеки, которая решает нашу проблему. Общая библиотека Websphere на самом деле представляет собой набор записей - каталогов или jarfiles - которые можно добавить в путь к классам для отдельного приложения. Мы определяем одну общую библиотеку для каждой среды - dev, тестирования и т. Д. - и помещаем файл свойств для каждой среды в правильный каталог.

Затем, при развертывании WAR, который должен работать как определенная среда - например, dev - мы добавляем ссылку на общую библиотеку dev в приложение. Каталог, определенный для разделяемой библиотеки dev, автоматически добавляется в путь к классам приложения.

Еще одно хакерское решение, которое мы рассматривали, - это добавить файл в каталог WEB-INF / classes WAR. Этот каталог автоматически добавляется в путь к классам приложения. Затем мы можем вызвать ClassLoader.getResource (), чтобы найти файл, и проанализировать путь к файлу, чтобы получить имя приложения. Дав каждому экземпляру развернутого приложения свое имя, приложение может выяснить, как оно должно инициализироваться.

Answer 2

Ссылки на ресурсы WebSphere, такие как ресурс URL, могут быть получены путем поиска в пространстве имен java: comp / env, следовательно, они связаны во время развертывания.Таким образом, вы можете выполнить развертывание дважды и привязать его к разным экземплярам - вы, вероятно, знакомы с этим для ресурсов JDBC.

Существуют различные варианты полезных ресурсов, которые можно использовать, например URL-адрес FILE.См. Информационный центр

Answer 3

@ kenster: использовать привязку пространства имен websphere.Например, вы можете создать привязку пространства имен (в разделе «Среда») с именем = корневым именем контекста приложения и значением = путем к файловой системе ... тогда вы можете извлечь привязку пространства имен с помощью JNDI в своем приложении, чтобы загрузить файл свойств из пути, указанного в значении.