альтернатива dfc.properties

Мы подключаемся к серверу documentum из программы Java (используя dfc.jar), чтобы получить документы. Чтобы подключиться к серверу, нам необходимо сделать dfc.properties доступным в пути к классам. У нас уже есть один главный файл свойств, поэтому мы хотим избежать еще одного. Вместо этого мы хотим поместить свойства в другой файл свойств, а затем использовать их при подключении к серверу documentum. Я мог найти, как использовать хост и порт docbroker из кода Java, то есть с помощью IDfTypedObject.

IDfLoginInfo loginInfoObj = clientX.getLoginInfo();
loginInfoObj.setUser(user);
loginInfoObj.setPassword(pwd);

IDfClient client = new DfClient();

IDfTypedObject cfg = client.getClientConfig();
cfg.setString("primary_host", "myhost");
cfg.setInt("primary_port", myport);

IDfSession docbase_session = client.newSession(docbase, loginInfoObj);

Подобно тому, как в коде устанавливаются primary_host и primary_port, есть ли способ установить через код следующие свойства из dfc.properties? dfc.globalregistry.repository dfc.globalregistry.имя пользователя dfc.globalregistry.password


documentum documentum-dfs
person Prasanna Hegde    schedule 14.11.2014    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Несмотря на то, что вам нужно иметь информацию о подключении к глобальному реестру, вам не нужно, чтобы эти данные были правильными. Конечно, если вы не хотите использовать функции BOF (TBO/SBO).

В вашем случае, если вам это не нужно (BOF), просто оставьте dfc.properties на месте с фиктивными данными для глобального реестра и продолжайте использовать код для динамической настройки деталей подключения к docbroker.

person Miki    schedule 14.11.2014

arrow_upward
6
arrow_downward

Свойства DFC должны находиться в отдельном файле. Однако этот файл может находиться вне самого приложения.

Вариант 1: включить

Поместите оператор include в начало dfc.properties пути к классам, чтобы указать на внешнюю конфигурацию, например:

#include /path/to/external/dfc.properties

Вы даже можете использовать гибридные подходы, включив несколько файлов и/или добавив/перезаписав dfc.properties вашего приложения:

#include /path/to/common/dfc.properties
#include /path/to/more/specific/dfc.properties     # may or may not override
<app specific parameters go here>                  # may or may not override

Вариант 2: переменная среды

Установите переменную среды dfc.properties.file так, чтобы она указывала на внешний dfc.properties. Измените запуск вашего сервера приложений примерно так:

java ... –Ddfc.properties.file=/path/to/external/dfc.properties ...

Если вы используете Tomcat, вы можете сделать это, установив системную переменную в самой ОС:

set JAVA_OPTS=–Ddfc.properties.file=/path/to/external/dfc.properties

Обобщить

Я бы не рекомендовал устанавливать параметры DFC в коде. Лучшей практикой является наличие отдельного файла конфигурации вне приложения. Помните, что ваша среда выполнения (JVM) должна иметь доступ к файловой системе по мере необходимости. Это относится к обоим вариантам выше.

person eivamu    schedule 14.11.2014
comment
Хорошо, я забыл об этой опции, хотя она часто используется в продуктах EMC. Но можно ли это настроить — например, с помощью переменных среды? - person Miki; 14.11.2014
comment
Да, я добавил дополнительный подход к своему ответу сейчас, после небольшого исследования :) - person eivamu; 14.11.2014

arrow_upward
0
arrow_downward

Просто добавим, что при использовании пути к классам для определения местоположения основных dfc.properties файл dfc.properties должен находиться в банке или zip-файле, иначе он будет проигнорирован.

person fastterapin    schedule 30.05.2017