2

I am working on a Java project and have a problem with Wildfly 10's deployment. I don't find the solution in its documentation and would appreciate some help.

When I deploy a .WAR, Wildfly creates a temporary folder to store the exploded files:

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

and as soon as I stop Wildfly with /etc/init.d/wildfly stop, all these temporary files are instantly deleted from the disk.

Problem:

The WAR contains default .properties files which have to be modified/configured by the administrator. Since the files are deleted with every deployment, this is not currently possible.

Questions:

  • Is there a way to have Wildfly deploys the .WAR to a permanent folder (similar to Apache Tomcat) ?
  • Is it a good J2E practice to do so considering the client wants to deploy this .WAR to a Debian Cloud infrastructure, but also occasionally to Windows Server?
  • What alternatives should we consider to store the .properties values?
Guillaume F.
  • 5,905
  • 2
  • 31
  • 59

1 Answers1

4

WildFly does support unzipped (exploded) deployments. Have a look at $JBOSS_HOME/standalone/deployments/README.txt for details. Basically, you can just unzip your WAR to a subdirectory and add a marker file to have it deployed.

However, any configuration information that depends on the given host environment should not be placed in the WAR. A WAR is a compile-time artifact which should be regarded as immutable at run-time. (The fact that some web containers unzip the WAR and expose its internals is an implementation detail you should never rely on.)

Instead, you can define configuration data via system properties, environment variables, JNDI entries, whatever.

A very simple approach I often use with WildFly is the -P option:

cd $JBOSS_HOME/bin
./standalone.sh -P myconfig.properties

where myconfig.properties is a simple Java properties file. WildFly reads this file very early in its start-up phase and sets all properties as system properties.

Being system properties, these configuration items will be visible to all deployments, which shouldn't be a problem as long as you control what gets deployed to your server. To avoid conflicts between properties for different deployments, you can use deployment specific prefixes for your property keys, e.g.

app1.jdbc.url = jdbc:postgresql://localhost/app1
app2.jdbc.url = jdbc:postgresql://localhost/app2
Harald Wellmann
  • 12,615
  • 4
  • 41
  • 63