JBoss Wildfly - deployment-а е от темпови файлове,а properties?

+6 гласа
41 прегледа
попитан 2016 юни 17 в Java от Nikola.Nikolov. (3,100 точки)

Работя над един Java проекти имам проблем с deployment-а на Wildfly 10. Не намирам решение в документацията и бих искал малко помощ.

Когато deploy-на .WAR, Wildfly създава темпова папка, която съдържа exploded файлове:

./standalone/tmp/vfs/temp/tempb75b67d7adb84a3d/web.war-47f6d3d54946006d/

и веднага щом спра Wildfly с /etc/init.d/wildfly stop ,всички тези временни файлове веднага се изтриват от диска.

Проблем:

WAR съдържа .properties файлове по подразбиране, които трябва да бъдат модифицирани/ конфигурирани от администратора. Понеже файловете се трият с всеки deployment, не е възможно.

Въпроси:

Има ли начин да направя така,че Wildfly да deploy-не .WAR  към перманентна папка (като Apache Tomcat)?

Добра J2E практика ли е да се направи така,като се има придвид,че потребителят иска да го deploy-не този .WAR към Debian Cloud infrastructure-а, но също така и може би към Windows сървър?

По какви други начини можем да съхраним стойностите на .properties?

1 отговор

0 гласа
отговорени 2016 юни 17 от Daniel Ivanov (11,160 точки)
избран 2016 юни 21 от Mitko Vasilev
 
Най-добър отговор

Така,

Wildfly съпортва unzip-нати (exploded) deployment-и. Виж в $JBOSS_HOME/standalone/deployments/README.txt за повече инфо. Като цяло трябва да разархивираш своя WAR в поддиректория и да добавиш marker file,за да го deploy-неш.

Въпреки това, каквато и да е конфугурационна информация, която зависи от зададения host environment, НЕ трябва да бъде в WAR. WAR-ът е compile-time artefact, който трябва да бъде възприеман като immutable по време на работа. (Фактът,че някои мрежови контейнери (web containers) разархивират WAR-а и разкриват вътрешностите, е имплементация,на която никога не трябва да се се осланяш.

Вместо това, можеш да дефинираш config. data-та през system properties,environment variables,       JNDI entry-тата и т.н.

Много лесен начин за изполване е начина с -P.

cd $JBOSS_HOME/bin

./standalone.sh -P myconfig.properties


където myconfig.properties е прост Java properties файл. WildFly чете този файл рано в своята стартираща фаза и настройва всички свойства (properties) като системни такива.


Когато са системни свойства, тези конфигурационни item-чета ще бъдат видими за всички deployment-и, което не би трябвало да е проблем докато си контролираш кое се качва на сървъра ти(кое се deploy-ва). За да избегнеш конфликти м/у properties за различни deployment-и, можеш да ползваш deployment-specific префикси за твоите property keys, например:


app1.jdbc.url = jdbc:postgresql://localhost/app1

app2.jdbc.url = jdbc:postgresql://localhost/app2

...