Сборка проекта в jar с последующим изменением файла .properties

программирование java
, , ,
#1

Доброго часа всем.

Мой вопрос заключается в следующем.

Есть приложение, которое ходит в БД и что-то там себе делает. Все хосты для подключения, логины и пароли вынесены в файл .properties.
Как правильно собрать приложение, или как его правильно “использовать”, в случае, если нужно изменить .properties файл (менять нужно постоянно). Приложение в перспективе будут использовать юзеры, у которых на машинах не установлена идея или мавен.

Что я пробовал: собирал простой jar-ник и вызывал mian-класс. Но если меняется конфиг - нужно пересобирать проект.

Подскажите, как быть

#2

читайте файл

		propertiesMap = PropertiesParser
				.getProperties(String.format("%s/src/main/resources/%s",
						System.getProperty("user.dir"), propertiesFileName));

здесь PropertiesParser это просто класс для чтения properties и превращения в Map<String, String>

#3

malo konteksta, no zvuchit kak to, cto uze realizovano v spring framework

https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-profile-specific-properties

#4

А у юзеров есть свои собственные credentials к БД? Или предполагается использование каких-то shared?

P.S. Вообще кредлы никто не хардкодит в пропертях. Jar можно легко распаковать и получить конфиденциальную инфу. Это нужно менеджить либо на уровне допустим system properties (передавая креденшалы прямо через command line в момент запуска), либо подсовывать внешний конфиг файл, который будет индивидуален для каждого юзера (по примеру maven settings.xml).

1 лайк
#5

Метод main принимает параметры, при запуске приложения передавайте путь к файлу с настройками и используйте этот путь для считывания оттуда инфы.
После сборки приложения просто запускаете с указанием пути.
java -jar app.jar bd.properties
java -jar app.jar c:\test\bd.properties
запустит приложение и возьмёт рядом лежащий bd.properties или из папки test

1 лайк
#6

Примерно так и делаю. Вопрос в том, чтобы потом проперти оперативно менять и не пересобирать проект после этого.

#7

В данном кейсе секьюрность мне не важна. Поэтому можно захардкодить в пропертях. Тоже думал над вариантом system properties, но немного неудобно, потому что как я понимаю, нужно при каждом выполнении приложения вводить креды. Запускать и перезапускать предполагается часто.

#8

Спасибо. Ваш вариант мне кажется самым оптимальным и подходящим. Попробую и отпишусь

#9

Не нужно, если запускать скриптом. :wink: К тому же, время, затрачиваемое на изменение кредлов в скрипте = времени изменения тех же данных во внешнем props файле.

Так что какого-либо очевидного профита от использования пропертей чисто для хранения 3 пар ключ-значение - нет (если только это не вынесено на уровень конвеншенов внутри компании).

Пользователи ведь наверняка уже итак запускают файл скриптом, чтобы каждый раз не писать java -jar blablabla. Не вижу проблемы добавить туда же +3 параметра.

Но в целом, исходя из того, что вам плевать на секьюрность, любой из предложенных вариантов подойдет.

#10

Посмотрите на GitHub - tatools/sunshine: Sunshine allows you to manage suits of your automated tests directly from Java code.. Там есть пример как передавать testng.xml. Можно сделать по аналогии.