Как избежать жесткого кодирования пути к файлу свойств

Question

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

Вот ситуация, которая существует сейчас.

У меня есть один сервер папок / Внутри которого есть 2 пакета core / & support / (оба из которых имеют много подпакетов внизу)

То, что я делал ранее, было то, где путь к файлу свойств был необходим длячтобы указать, я просто дал относительный путь, т.е. свойства / В этом сценарии файл свойств должен быть там, откуда вы запускаете программу.Это работало во время тестирования, когда я вручную запускал программу, используя "Java".и я бы положил папку свойств, где я запускаю программу.Но в реальном сценарии эта программа будет автоматически запускаться сценарием (ksh), который выполняется заданием через запланированные промежутки времени.

В этом случае задание относительного пути не работает.Я попытался поместить файлы свойств в папку, в которой расположены сценарии, но это тоже не работает.

Сейчас мне приходится вручную указывать путь для каждой среды, перекомпилировать код и развертывать отдельныйКопировать для каждой среды.Есть ли способ удалить эту связь и иметь только одно место для файла свойств независимо от того, где его нужно развернуть?

Answer 1

используйте запись System.Properties, чтобы указать путь, затем в командной строке добавьте его через

java -DmyProp=somepath -cp yourclasspath YourClass

. В своем приложении вы можете получить его с помощью System.getProperty("myProp"), просто обязательно добавьте соответствующее тестирование.и обработайте сценарий «Свойство не найдено».

Другая практика - оставлять реквизиты в банке, а затем загружать их с помощью LoadResource. Таким образом, вам просто нужно развернуть различные конфигурационные файлы в каждом развертывании, но я думаю,что способ System.setProperty является самым быстрым.

Answer 2

Я передал другой параметр classpath с вызовом jar.

java -cp classpath1;folder-where-propertiesfile-located Application.jar

и в приложении использовал getClass().getClassLoader().getResourcesAsStream("properties-file");

. Это автоматически приведетфайл свойств формирует соответствующую папку classpath ..

При этой настройке я могу изменить файл свойств внутри папки и использовать тот же файл jar без повторного архивирования jar ..

Answer 3

Как правило, некоторые клиенты могут не использовать -D = при запуске приложения. На самом деле вы должны также предоставить файл сценария .sh / .bat вместе с файлом jar, чтобы клиент мог просто дважды щелкнуть сценарий для запуска приложения.

В этом скрипте вы можете иметь объявленную переменную, которую вы можете попросить клиента настроить соответствующим образом. Клиент может просто открыть файл сценария в текстовом редакторе и ввести путь к файлу конфигурации.

Другой способ использования этого файла сценария заключается в следующем: 1) Проверьте, установлена ​​ли переменная YOUR_APP_NAME_CONFIG в системной среде. Если да, то перейдите к шагу 3 или перейдите к шагу 2 2) Узнайте у пользователя в командной строке, где находится файл конфигурации. Проверьте правильность расположения. Если правильно, установите переменную среды YOUR_APP_NAME_CONFIG со значением местоположения файла конфигурации. 3) Запустите ваше приложение

Наличие файла сценария для вашего приложения дает вам большую свободу в работе по автоматизации конфигурации среды для вашего приложения. В вашем приложении получите путь к файлу конфигурации по System.getProperty («YOUR_APP_NAME_CONFIG»).

Все это может показаться большой болью, но подумайте с точки зрения клиента. Для клиента это просто прогулка: он просто дважды щелкает скрипт, чтобы запустить ваше приложение, и при первом запуске приложения скрипт запрашивает некоторые входные данные, если это необходимо, и тогда ваше приложение готово к работе:)