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

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


java properties websphere jakarta-ee websphere-8
person invariant    schedule 23.05.2014    source источник

Ответы (6)


arrow_upward
1
arrow_downward

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

Проверьте Страница загрузчиков классов.

person groo    schedule 23.05.2014
comment
Вы можете прочитать мой ответ, чтобы узнать, почему не рекомендуется размещать элементы в WAS_HOME/classes. - person Isaac; 25.05.2014
comment
Я не согласен с вашими аргументами в этом случае. Если бы он спросил о том, как реализовать свойства для конкретного приложения, я бы использовал общие библиотеки, как вы упомянули в своем ответе. Но он был очень конкретен, прося разрешения сделать свойства доступными на всех узлах кластера. - person groo; 26.05.2014
comment
Все равно не поможет. Для горизонтальной кластеризации вам в любом случае придется делать это на каждом физическом узле. Подход AppServer / классы не экономит работы; он вводит больше ограничений, чем преимуществ. - person Isaac; 27.05.2014
comment
@Isaac - я по-прежнему считаю, что это намного проще, практичнее, меньше подвержено человеческим ошибкам и лучше в этом конкретном случае (для всех серверов в кластере), чем настраивать общие библиотеки во всех приложениях. Также общая библиотека имеет точно такую ​​же проблему при горизонтальном кластеризации (вам придется делать это во всех физических узлах + приложениях). - person groo; 27.05.2014

arrow_upward
8
arrow_downward

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

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

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

person Gas    schedule 03.06.2014
comment
Я добавил новый файл свойств в каталог PROFILE_ROOT / properties, но когда мое приложение ищет файл, я получаю исключение FileNotFound. С другой стороны, приложение может найти существующие файлы свойств. Нужно ли мне выполнять какие-либо действия, чтобы новый файл был распознан? - person user12222; 01.04.2015
comment
@SreeramJayan Используете ли вы метод getResourceAsStream() для получения входного потока? Как вы пытаетесь загрузить свойства? - person Gas; 01.04.2015
comment
Я загружаю файл свойств с помощью FileInputStream. - person user12222; 01.04.2015
comment
@SreeramJayan Это причина :-). Потому что эта папка находится не в пути к файлу, а в пути к классам. Вам нужно будет заменить ваш метод на getResourceAsStream() из ServletContext или ClassLoader, в зависимости от ваших потребностей. - person Gas; 01.04.2015
comment
Но как я могу загружать другие файлы свойств в том же каталоге с помощью FileInputStream? - person user12222; 01.04.2015
comment
@SreeramJayan В этом нет никакого волшебства, если вы можете загрузить другие файлы свойств из того же каталога, то либо у вас есть ошибка в пути / имени файла, либо у вас нет права на чтение файла (особенно это возможно в Linux). - person Gas; 02.04.2015

arrow_upward
7
arrow_downward

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

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

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

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

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

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

    • To attach the Shared Library to the server, create a new Classloader element on the server and attach the shared library to it.
    • Чтобы присоединить общую библиотеку к приложению, выполните вложение, отредактировав свойства EAR в консоли администрирования или с помощью параметров развертывания по сценарию.
person Isaac    schedule 25.05.2014
comment
Голосующий против: не хотите ли объяснить, что не так с моим ответом? - person Isaac; 26.05.2014
comment
Привет извините. Я не объяснил, потому что в то время я разговаривал по мобильному телефону. Я отклонил ваш ответ по нескольким причинам. - person groo; 26.05.2014
comment
Я отклонил ваш ответ по нескольким причинам. 1) Он очень конкретно ответил на свой вопрос, задав решение, которое должно быть доступно для всех узлов в кластере. 2) Он ничего не упомянул о портале WAS или других продуктах, поэтому ваша точка зрения на использование этого каталога другими продуктами - это просто беспокойство о вещах, которые могут никогда не произойти (в большинстве случаев). 3) Решение с общей библиотекой намного сложнее и в этом случае подвержено ошибкам (это действительно верно, если вы хотите, чтобы только одно приложение имело доступ к свойствам, а не ко всему кластеру). - person groo; 26.05.2014
comment
Я уважаю ваш подход, но могу сказать, что я из тех парней, которые предпочитают простоту попыткам быть полностью совместимыми и совершенными в решениях. иначе - я предпочитаю простоту использования и ясность кода производительности, пока производительность не станет проблемой. - person groo; 27.05.2014
comment
@Isaac, спасибо за ваш ответ, если размещение папки классов является проблемой только на сервере портала .., я все еще чувствую, что текущий принятый ответ проще, чем общие библиотеки, поскольку я не использую какой-либо сервер портала .. - person invariant; 27.05.2014
comment
@invariant нет проблем. Каждому свое! (Между прочим: WebSphere Portal был всего лишь примером.) - person Isaac; 27.05.2014

arrow_upward
2
arrow_downward

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

Затем определите URL-адреса в Websphere, используя консоль администратора, чтобы они указывали, например, на «file: ///dev.properties» или «file: ///test.properties».

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

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

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

person Greycon    schedule 09.07.2014
comment
Я предпочитаю шаблон передовой практики для настройки приложения. Дополнительную информацию можно найти на ibm.com/support/knowledgecenter/SSAW57_8.5.5/ - person Ben Asmussen; 14.09.2020
comment
@BenAsmussen Привет, ты можешь уточнить? Я просмотрел предоставленную вами ссылку, и это в значительной степени то, что я описал? Может я не очень хорошо это описал :-( - person Greycon; 14.09.2020
comment
Ваши объяснения верны, но способ настройки не совсем понятен из вашего сообщения. Отсюда ссылка и примечание о том, что IBM предлагает загрузку URL-адреса. :-) - person Ben Asmussen; 14.09.2020

arrow_upward
1
arrow_downward

попробуй это

  1. Создайте каталог (по вашему выбору) для хранения файла свойств.
  2. Добавьте каталог в WebSphere CLASSPATH.
  3. Загрузите файл свойств из CLASSPATH.
person DwB    schedule 23.05.2014

arrow_upward
0
arrow_downward

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

person user3669895    schedule 23.05.2014