WildFly System Properties
Internal
Overview
System properties can be declared in the server's configuration files and are propagated to the server JVMs and implicitly to applications. For more details on how system property can be declared, see Declaration in Configuration Files] below.
Declaration in Configuration Files
Standalone Mode
Domain Mode
Declaration in domain.xml
Top Level
System properties can be declared in domain.xml at the top of the file, conventionally right under the <extensions> element:
<domain ...>
<extensions>
...
</extensions>
<system-properties>
<property name="a.system.property.available.across.the.entire.domain" value="some value/>
</system-properties>
...
</domain>
These properties are available to all server groups, across the entire domain.
Server Group
<domain ...>
...
<server-groups>
<server-group name="server-group-one" ...>
<system-properties>
<property name="a.system.property.available.only.to.server.group.one" value="some value"/>
</system-properties>
...
</server-group>
</server-groups>
</domain>
These properties are only available to servers belonging to the server group the property was declared in.
Declaration in host.xml
<host ...>
<extensions>
...
</extensions>
<system-properties>
<property name="a.system.property.available.to.servers.on.this.host" value="some value/>
</system-properties>
...
</domain>
These properties are available to all servers executing on the host, and are not available to servers executed on other hosts.
Reference in Configuration Files
System property references can be specified in such a way that a default value is provided. The default value is provided if the system property is not defined.
...
<backup>${jboss.messaging.hornetq.backup:false}</backup>
...
Reference in Other System Properties
System properties can be referred from other system properties, and they will be replaced at runtime, under some circumstances, and according to the following precedence rules:
- Properties declared at server group level do not accept references, and generate a configuration error is they see one: WFLYCTL0211: Cannot resolve expression '${a.test}'.
- Referring a property declared on the same level (same <system-properties> block) is not replaced, but left in the "${...}" form.
- A property reference declared in a domain level property definition is not replaced with the value of the property declared in the server group.
System Property Management with CLI
System Properties and Standard Paths
Standard System Properties
jboss.qualified.host.name
Relevance: WildFly 9
For a host named "ap1.modcluster.local" it is set to "ap1.modcluster.local"
The value of the first segment of this system property will override the <host> element name attribute in host.xml. For more details see host.xml <host> name.
jboss.host.name
Relevance: WildFly 9
For a host named "ap1.modcluster.local" it is set to "ap1".
The value of this system property will override the <host> element name attribute in host.xml. For more details see host.xml <host> name.
jboss.server.name
Relevance: WildFly 9
For a host named "ap1.modcluster.local" it is set to "ap1"
jboss.node.name
Relevance: WildFly 9
Set externally with -Djboss.node.name in the startup script.
Related:
- 'jboss.node.name' in mod_cluster Concepts
- 'jboss.node.name' and the JBoss startup script
- Transaction Subsystem Configuration - Unique Node Identifier
jboss.server.config.dir
Used by:
jboss.bind.address
Represents the value of the instance's public interface. The default value is 127.0.0.1. Also see
jboss.bind.address for Standalone Node
One common method of externalizing this operationally is to define it as a system property at the bottom of $JBOSS_HOME/bin/standalone.conf:
...
JAVA_HOME="${JAVA_HOME} -Djboss.bind.address=192.168.1.15"
The same result can be achieved by specifying the system property as a -D argument for the start script:
./standalone.sh -Djboss.bind.address=192.168.1.10
jboss.bind.address for Host Controller
One common method to externalize the value operationally for host controllers is to define it as a system property at the bottom of $JBOSS_HOME/bin/domain.conf as follows:
...
HOST_CONTROLLER_JAVA_OPTS="${HOST_CONTROLLER_JAVA_OPTS} -Djboss.bind.address=1.2.3.4"
The value propagates as system property to the process controller, host controller and servers:
eap 13556 13457 java -D[Process Controller] ... -Djboss.bind.address=1.2.3.4 ... eap 13595 13556 java -D[Host Controller] ... -Djboss.bind.address=1.2.3.4 ... eap 13750 13556 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79.x86_64/jre/bin/java -D[Server:ri2] ... -Djboss.bind.address=1.2.3.4 ...
Also see
jboss.bind.address.management
The value of the instance's management interface bind address. The default value is 127.0.0.1.
jboss.bind.address.management for Standalone Node
One common method of externalizing this operationally is to define it as a system property at the bottom of $JBOSS_HOME/bin/standalone.conf:
...
JAVA_HOME="${JAVA_HOME} -Djboss.bind.address.management=192.168.1.15"
The same result can be achieved by specifying the system property as a -D argument for the start script:
./standalone.sh -Djboss.bind.address.management=192.168.1.10
jboss.bind.address.management for Host and Domain Controller
One common method to externalize the value operationally for host and domain controllers is to define it as a system property at the bottom of $JBOSS_HOME/bin/domain.conf as follows:
...
HOST_CONTROLLER_JAVA_OPTS="${HOST_CONTROLLER_JAVA_OPTS} -Djboss.bind.address.management=1.2.3.4"
Note that an attempt to set jboss.bind.address.management in the <system-properties> section of host.xml did not seem to work.
jboss.bind.address.private
The value to bind the "private" interface to. By default 127.0.0.1.
jboss.bind.address.unsecure
The value to bind the "unsecure" interface to. By default 127.0.0.1.
jboss.domain.master.address
The hostname of the domain controller.
It is actually not a good idea to externalize the master domain controller address as a system property. For more explanations see:
jboss.domain.master.port
The port of the domain controller process.