To start up a WildFly 8 managed domain, execute the $JBOSS_HOME/bin/domain.sh script. To start up a standalone server, execute the $JBOSS_HOME/bin/standalone.sh. With no arguments, the default configuration is used. You can override the default configuration by providing arguments on the command line, or in your calling script.
The standalone and the managed domain modes each use a default configuration which expects various files and writable directories to exist in standard locations. Each of these standard locations is associated with a system property, which has a default value. To override a system property, pass its new value using the standard jvm -Dkey=value options:
This command starts up a standalone server instance using a non-standard AS home directory and a custom configuration directory. For specific information about system properties, refer to the definitions below.
Instead of passing the parameters directly, you can put them into a properties file, and pass the properties file to the script, as in the two examples below.
The syntax for passing in parameters and properties files is the same regardless of whether you are running the domain.sh, standalone.sh, or the Microsoft Windows scriptsdomain.bat or standalone.bat.
The properties file is a standard Java property file containing key=value pairs:
|Property name||Usage||Default value|
|java.ext.dirs||The JDK extension directory paths||null|
|jboss.home.dir||The root directory of the WildFly 8 installation.||Set by standalone.sh to $JBOSS_HOME|
|jboss.server.base.dir||The base directory for server content.||jboss.home.dir/standalone|
|jboss.server.config.dir||The base configuration directory.||jboss.server.base.dir/configuration|
|jboss.server.data.dir||The directory used for persistent data file storage.||jboss.server.base.dir/data|
|jboss.server.log.dir||The directory containing the server.log file.||jboss.server.base.dir/log|
|jboss.server.temp.dir||The directory used for temporary file storage.||jboss.server.base.dir/tmp|
|jboss.server.deploy.dir||The directory used to store deployed content||jboss.server.data.dir/content|
|Property name||Usage||Default value|
|jboss.home.dir||The root directory of the WildFly installation.||Set by domain.sh to $JBOSS_HOME|
|jboss.domain.base.dir||The base directory for domain content.||jboss.home.dir/domain|
|jboss.domain.config.dir||The base configuration directory||jboss.domain.base.dir/configuration|
|jboss.domain.data.dir||The directory used for persistent data file storage.||jboss.domain.base.dir/data|
|jboss.domain.log.dir||The directory containing the host-controller.log and process-controller.log files||jboss.domain.base.dir/log|
|jboss.domain.temp.dir||The directory used for temporary file storage||jboss.domain.base.dir/tmp|
|jboss.domain.deployment.dir||The directory used to store deployed content||jboss.domain.base.dir/content|
|jboss.domain.servers.dir||The directory containing the output for the managed server instances||jboss.domain.base.dir/servers|
The first acceptable format for command line arguments to the WildFly launch scripts is
If the parameter name is a single character, it is prefixed by a single '-' instead of two. Some parameters have both a long and short option.
For some command line arguments frequently used in previous major releases of WildFly, replacing the "=" in the above examples with a space is supported, for compatibility.
If possible, use the -x=value syntax. New parameters will always support this syntax.
The sections below describe the command line parameter names that are available in standalone and domain mode.
|Name||Default if absent||Value|
|jboss.server.config.dir/standalone.xml||A relative path which is interpreted to be relative to jboss.server.config.dir.|
|--read-only-server-config||-||A relative path which is interpreted to be relative to jboss.server.config.dir. This is similar to --server-config but it does not overwrite the file used when the management model is changed. However a full versioned history is maintained of the file.|
|Name||Default if absent||Value|
|jboss.domain.config.dir/domain.xml||A relative path which is interpreted to be relative to jboss.domain.config.dir.|
|--read-only-domain-config||-||A relative path which is interpreted to be relative to jboss.domain.config.dir. This is similar to --domain-config but it does not overwrite the file used when the management model is changed. However a full versioned history is maintained of the file.|
|--host-config||jboss.domain.config.dir/host.xml||A relative path which is interpreted to be relative to jboss.domain.config.dir.|
|--read-only-host-config||-||A relative path which is interpreted to be relative to jboss.domain.config.dir. This is similar to --host-config but it does not overwrite the file used when the management model is changed. However a full versioned history is maintained of the file.|
The following parameters take no value and are only usable on slave host controllers (i.e. hosts configured to connect to a remote domain controller.)
|--backup||Causes the slave host controller to create and maintain a local copy of the domain configuration file|
|--cached-dc||If the slave host controller is unable to contact the master domain controller to get its configuration at boot, boot from a local copy previously created using --backup. The slave host controller will not be able make any modifications to the domain configuration, but it will be able to launch servers.|
These parameters apply in both standalone or managed domain mode:
|-b=<value>||Sets system property jboss.bind.address to <value>. See Controlling the Bind Address with -b for further details.|
|-b<name>=<value>||Sets system property jboss.bind.address.<name> to <value> where name can vary. See Controlling the Bind Address with -b for further details.|
|-u=<value>||Sets system property jboss.default.multicast.address to <value>. See Controlling the Default Multicast Address with -u for further details.|
|Prints the version of WildFly to standard output and exits the JVM.|
|Prints a help message explaining the options and exits the JVM.|
WildFly binds sockets to the IP addresses and interfaces contained in the <interfaces> elements in standalone.xml, domain.xml and host.xml. (See Interfaces and Socket Bindings for further information on these elements.) The standard configurations that ship with WildFly includes two interface configurations:
Those configurations use the values of system properties jboss.bind.address.management and jboss.bind.address if they are set. If they are not set, 127.0.0.1 is used for each value.
As noted in Common Parameters, the AS supports the -b and -b<name> command line switches. The only function of these switches is to set system properties jboss.bind.address and jboss.bind.address.<name> respectively. However, because of the way the standard WildFly configuration files are set up, using the -b switches can indirectly control how the AS binds sockets.
If your interface configurations match those shown above, using this as your launch command causes all sockets associated with interface named "public" to be bound to 192.168.100.10.
In the standard config files, public interfaces are those not associated with server management. Public interfaces handle normal end-user requests.
The interface named "public" is not inherently special. It is provided as a convenience. You can name your interfaces to suit your environment.
To bind the public interfaces to all IPv4 addresses (the IPv4 wildcard address), use the following syntax:
You can also bind the management interfaces, as follows:
In the standard config files, management interfaces are those sockets associated with server management, such as the socket used by the CLI, the HTTP socket used by the admin console, and the JMX connector socket.
The -b switch only controls the interface bindings because the standard config files that ship with WildFly sets things up that way. If you change the <interfaces> section in your configuration to ignore the system properties controlled by -b, then setting -b in your launch command will have no effect.
For example, this perfectly valid setting for the "public" interface causes -b to have no effect on the "public" interface:
The key point is the contents of the configuration files determine the configuration. Settings like -b are not overrides of the configuration files. They only provide a shorter syntax for setting a system properties that may or may not be referenced in the configuration files. They are provided as a convenience, and you can choose to modify your configuration to ignore them.
WildFly 8 may use multicast communication for some services, particularly those involving high availability clustering. The multicast addresses and ports used are configured using the socket-binding elements in standalone.xml and domain.xml. (See Socket Bindings for further information on these elements.) The standard HA configurations that ship with WildFly include two socket binding configurations that use a default multicast address:
Those configurations use the values of system property jboss.default.multicast.address if it is set. If it is not set, 220.127.116.11 is used for each value. (The configuration may include other socket bindings for multicast-based services that are not meant to use the default multicast address; e.g. a binding the mod-cluster services use to communicate on a separate address/port with Apache httpd servers.)
As noted in Common Parameters, the AS supports the -u command line switch. The only function of this switch is to set system property jboss.default.multicast.address. However, because of the way the standard AS configuration files are set up, using the -u switches can indirectly control how the AS uses multicast.
If your socket binding configurations match those shown above, using this as your launch command causes the service using those sockets configurations to be communicate over multicast address 18.104.22.168.
As with the -b switch, the -u switch only controls the multicast address used because the standard config files that ship with WildFly 8 sets things up that way. If you change the <socket-binding> sections in your configuration to ignore the system properties controlled by -u, then setting -u in your launch command will have no effect.