Така,
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
