лучшее место для размещения файла свойств в IBM websphere 8.5?

в наш существующий файл свойств приложения встроен в файл jar, мы решили переместить файл свойств за пределы ear (application) , какое лучшее место для размещения файла свойств в IBM websphere 8.5 ? так что я могу получить путь с переменными окружения и файл должен быть доступен для всех узлов в кластере ..

7
java java-ee properties websphere websphere-8

6 ответов

для этого вы можете использовать каталоги classloader. Я бы использовал классы каталогов (вам может потребоваться создать) под $WEBSPHERE_HOME/AppServer / classes и отбросил бы ваши свойства там. Вы должны быть в состоянии найти их с любого из ваших приложений / серверов.

Регистрация страница загрузчиков классов.

0

Вопреки (в настоящее время) принятому ответу, я утверждаю, что размещение чего-либо под WAS_HOME/classes - это уныние практике. Этот каталог часто используется IBM для размещения классов / файлов JAR, которые считаются "внутренними" для WAS и связанных продуктов (например, некоторые версии WebSphere Portal помещают файлы JAR в этот каталог).

кроме того, размещение элементов в WAS_HOME/classes товары доступны для все приложения работает на все профили создано это была установка. Вы не можете изменить это поведение;так было задумано. Это еще одна причина сделать вывод, что WAS_HOME/classes следует зарезервировать для внутреннего использования WAS.

этот аргумент можно обобщить практически на любой местоположение под WAS_HOME: пользовательские файлы (то есть файлы, не предоставленные поставщиком программного обеспечения) не должны находиться в местах, управляемых установщиком/деинсталлятором продукта. The WAS_HOME иерархией управляет IBM Installation Manager (или установщик WAS, в зависимости от рассматриваемой версии WAS). Я бы не стал туда класть свои файлы.

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

  1. создать каталог за пределами дерево каталогов WAS и поместите туда свои файлы.
  2. в WAS создайте общую библиотеку определение.
  3. добавьте созданный каталог в общую библиотеку.

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

    • чтобы присоединить общую библиотеку к серверу, создайте на сервере новый элемент Classloader и присоедините к нему общую библиотеку.
    • чтобы присоединить общую библиотеку к приложению, выполните вложение путем редактирования Свойства EAR в консоли администрирования или через параметры развертывания по сценарию.
7

только мои 2 цента в обсуждении.

для быстрого и простого решения я бы поместил файл свойств не в WAS_HOME / classes, а в PROFILE_ROOT / properties - эта папка находится на пути к классам, и она используется для хранения свойств в любом случае. Одно преимущество над / classes-это область профиля, поэтому, если у вас разные профили, например, для тестирования или интеграции, они могут иметь разные настройки.

и для "чистого" решения WebSphere это позволит управлять свойства через консоль вы можете проверить поставщиков среды ресурсов (но его довольно длинное, сложное решение): http://www.ibm.com/developerworks/websphere/library/techarticles/0611_totapally/0611_totapally.html

7

попробуй такое

  1. создайте каталог (местоположение по вашему выбору) для хранения файла свойств.
  2. добавьте каталог в путь к классам WebSphere.
  3. загрузите файл свойств из пути к классам.
1

другое решение, которое я использую, - добавить ссылку на URL-ресурс в веб-приложение.XML. Например, "url / properties".

затем определите URL-адреса в Websphere, используя консоль администратора, чтобы указать на " file: / / / dev.свойства", или " файл: / / / тест.свойства", например.

затем во время развертывания сопоставьте ссылку URL с соответствующим определением URL websphere.

теперь ваш код может просто выполнить поиск JNDI URL-адреса.

Это преимущество в том, что можно развернуть одну кодовую базу и настроить во время развертывания для указания различных URL-адресов.

1

база данных-лучшее место для размещения свойств, если значения свойств не относятся к одному узлу кластера или значение свойства является паролем. Для свойств, таких как пароли, я бы предложил вам настроить значения свойств как свойства jndi в WAS. Используйте конфигурацию commons Для чтения из обоих источников. Иметь.файл свойств в вашей кодовой базе, который переопределит значения как из db, так и из jndi. Таким образом, ваши разработчики могут переопределить значения db/jndi в развитие.

0