WildFly System Properties: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(64 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Internal=
=Internal=


* [[JBoss#Subjects|JBoss]]
* [[WildFly#Subjects|WildFly]]


=jboss.qualified.host.name=
=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|Declaration in Configuration Files]] below.
 
=Declaration in Configuration Files=
 
==Standalone Mode==
 
System properties can be declared in <tt>standalone*.xml</tt> at the top of the file, conventionally right under the <tt><extensions></tt> element:
 
<pre>
<server ...>
    <extensions>
      ...
    </extensions>
 
    <system-properties>
        <property name="a.system.property.available.to.the.server.instance" value="some value"/>
    </system-properties>
    ...
</server>
</pre>
 
It seems that properties declared this way are not reported in server.log, at least not in EAP 7, under:
 
<pre>
2017-03-27 09:51:02,353 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
        [Standalone] =
        awt.toolkit = sun.lwawt.macosx.LWCToolkit
        file.encoding = UTF-8
        file.encoding.pkg = sun.io
        ...
</pre>
 
==Domain Mode==
 
System properties declared as described below are reported in server.log, at least not in EAP 7, unlike in [[#Standalone_Mode|standalone*.xml case]].
 
===Declaration in domain.xml===
 
====Top Level====
 
System properties can be declared in <tt>domain.xml</tt> at the top of the file, conventionally right under the <tt><extensions></tt> element:
 
<pre>
<domain ...>
    <extensions>
      ...
    </extensions>
 
    <system-properties>
        <property name="a.system.property.available.across.the.entire.domain" value="some value"/>
    </system-properties>
    ...
</domain>
</pre>
 
These properties are available to all server groups, across the entire domain.
 
====Server Group====
 
<pre>
<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>
</pre>
 
These properties are only available to servers belonging to the server group the property was declared in.
 
The fact that we are able to specify different properties (or same properties with different values) for different server groups allows us to use a single profile with multiple server groups, if the differences in configuration between server groups can be expressed as values of system properties. The following example shows how to declare different MDB container pool sizes for servers belonging to two different groups:
 
{{Internal|Using Same Profile but Different Configuration for Different Server Groups|Using Same Profile but Different Configuration for Different Server Groups}}
 
===Declaration in host.xml===
 
System properties can be declared at the top of <tt>host.xml</tt>, right under the <extensions> element, applying to '''all''' servers on that host, as shown below:
 
<syntaxhighlight lang='xml'>
<host ...>
    <extensions>
      ...
    </extensions>
 
    <system-properties>
        <property name="a.system.property.available.to.servers.on.this.host" value="some value/>
    </system-properties>
    ...
</domain>
</syntaxhighlight>
 
or under <servers><server> elements, applying only to the specific servers they are declared for:
 
<syntaxhighlight lang='xml'>
<host ...>
    ...
  <servers>
      <server name="A" group="red">
          <system-properties>
              <property name="a.system.property.available.to.serverA.only" value="something"/>
          </system-properties>
      </server>
  </servers>
</domain>
</syntaxhighlight>
 
These properties are available to all servers executing on the host, and are ''not'' available to servers executed on other hosts.
 
=System Property 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.
 
<pre>
  ...
  <backup>${jboss.messaging.hornetq.backup:false}</backup>
  ...
</pre>
 
==System Property Reference in Other System Properties==
 
At least as per EAP 7, referring system properties from custom system properties declared in a <system-properties> block does not seem to work reliably: in the best case, properties are not replaced and left in the ${...} form, and in some cases, referring a property generates a configuration error:
 
<pre>
2017-03-21 13:13:51,332 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0008: Failed to start server (app01): java.lang.IllegalStateException: WFLYCTL0211: Cannot resolve expression 'includes ${a.domain}'
...
Caused by: org.jboss.as.controller.OperationFailedException: WFLYCTL0211: Cannot resolve expression 'includes ${a.domain}' [ "WFLYCTL0211: Cannot resolve expression 'includes ${a.domain}'" ]
        at org.jboss.as.controller.ExpressionResolverImpl.parseAndResolve(ExpressionResolverImpl.java:282)
        at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionStringRecursively(ExpressionResolverImpl.java:142)
        at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:84)
        at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:66)
</pre>
 
=System Property Management with CLI=
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly CLI - Manipulating System Properties|Manipulating System Properties]]
</blockquote>
 
=System Properties and Standard Paths=
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly Standard Paths]]
</blockquote>
 
=Standard System Properties=
 
==jboss.qualified.host.name==


Relevance: WildFly 9
Relevance: WildFly 9
Line 9: Line 162:
For a host named "ap1.modcluster.local" it is set to "ap1.modcluster.local"
For a host named "ap1.modcluster.local" it is set to "ap1.modcluster.local"


=jboss.host.name=
The value of the first segment of this system property will override the <tt><host></tt> element <tt>name</tt> attribute in <tt>host.xml</tt>. For more details see [[host.xml#Host_Name|host.xml <host> name]].
 
==jboss.host.name==


Relevance: WildFly 9
Relevance: WildFly 9


For a host named "ap1.modcluster.local" it is set to "ap1"
For a host named "ap1.modcluster.local" it is set to "ap1".
 
The value of this system property will override the <tt><host></tt> element <tt>name</tt> attribute in <tt>host.xml</tt>. For more details see [[host.xml#Host_Name|host.xml <host> name]].


=jboss.server.name=
==jboss.server.name==


Relevance: WildFly 9
Relevance: WildFly 9
Line 21: Line 178:
For a host named "ap1.modcluster.local" it is set to "ap1"
For a host named "ap1.modcluster.local" it is set to "ap1"


=jboss.node.name=
==jboss.node.name==


Relevance: WildFly 9
Relevance: WildFly 9
jboss.node.name


Set externally with <tt>-Djboss.node.name</tt> in the startup script.
Set externally with <tt>-Djboss.node.name</tt> in the startup script.
Line 33: Line 188:
* [[mod_cluster Concepts#jboss.node.name|'jboss.node.name' in mod_cluster Concepts]]
* [[mod_cluster Concepts#jboss.node.name|'jboss.node.name' in mod_cluster Concepts]]
* [[WildFly Isolated Self-Contained Standalone Profile#jboss.node.name|'jboss.node.name' and the JBoss startup script]]
* [[WildFly Isolated Self-Contained Standalone Profile#jboss.node.name|'jboss.node.name' and the JBoss startup script]]
* [[WildFly_Transaction_Subsystem_Configuration#Set_Unique_Node_Identifier|Transaction Subsystem Configuration - Unique Node Identifier]]


=jboss.server.config.dir=
==jboss.server.config.dir==


Used by:
Used by:
* [[WildFly Management API Configuration#Management_Realm_Configuration_Files|Management API Configuration]]
* [[WildFly Management API Configuration#Management_Realm_Configuration_Files|Management API Configuration]]


=jboss.bind.address=
==jboss.bind.address==


Represents the value of the instance's public interface. The default value is 127.0.0.1.
Represents the value of the instance's public interface. The default value is 127.0.0.1. Also see {{Internal|WildFly Interface Configuration#Public|Public Interface Configuration}}


==jboss.bind.address for Standalone Node==
===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 <tt>$JBOSS_HOME/bin/standalone.conf</tt>:
One common method of externalizing this operationally is to define it as a system property at the bottom of <tt>$JBOSS_HOME/bin/standalone.conf</tt>:
Line 58: Line 214:
</pre>
</pre>


==jboss.bind.address for Host Controller==
===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 <tt>$JBOSS_HOME/bin/domain.conf</tt> as follows:
 
<pre>
...
HOST_CONTROLLER_JAVA_OPTS="${HOST_CONTROLLER_JAVA_OPTS} -Djboss.bind.address=1.2.3.4"
</pre>
 
The value propagates as system property to the process controller, host controller '''and''' servers:
 
<pre>
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 ...
</pre>
 
Also see {{Internal|WildFly Interface Configuration#Public|Public Interface Configuration}}
 
==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 <tt>$JBOSS_HOME/bin/standalone.conf</tt>:
 
<pre>
...
JAVA_HOME="${JAVA_HOME} -Djboss.bind.address.management=192.168.1.15"
</pre>
 
The same result can be achieved by specifying the system property as a <tt>-D</tt> argument for the start script:
 
<pre>
./standalone.sh -Djboss.bind.address.management=192.168.1.10
</pre>
 
===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 <tt>$JBOSS_HOME/bin/domain.conf</tt> as follows:
 
<pre>
...
HOST_CONTROLLER_JAVA_OPTS="${HOST_CONTROLLER_JAVA_OPTS} -Djboss.bind.address.management=1.2.3.4"
 
</pre>
 
<blockquote style="background-color: Gold; border: solid thin Goldenrod;">
:<br>Note that an attempt to set jboss.bind.address.management in the <system-properties> section of host.xml did not seem to work.<br><br>
</blockquote>
 
==jboss.bind.address.private==
 
The value to bind the "private" interface to. By default 127.0.0.1.
 
===jboss.bind.address.private for Standalone Node===
 
Define it as a system property at the bottom of <tt>$JBOSS_HOME/bin/standalone.conf</tt>:
 
<pre>
...
JAVA_HOME="${JAVA_HOME} -Djboss.bind.address.private=192.168.1.15"
</pre>
 
The same result can be achieved by specifying the system property as a <tt>-D</tt> argument for the start script:
 
<pre>
./standalone.sh -Djboss.bind.address.private=192.168.1.10
</pre>
 
===jboss.bind.address.private 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 <tt>$JBOSS_HOME/bin/domain.conf</tt> as follows:
One common method to externalize the value operationally for host controllers is to define it as a system property at the bottom of <tt>$JBOSS_HOME/bin/domain.conf</tt> as follows:


=jboss.bind.address.management=
<pre>
...
HOST_CONTROLLER_JAVA_OPTS="${HOST_CONTROLLER_JAVA_OPTS} -Djboss.bind.address.private=1.2.3.4"
</pre>
 
The value propagates as system property to the process controller, host controller '''and''' servers.
 
==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:
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Subordinate WildFly Host Controller Post-Install Configuration#Specify_the_Master_Domain_Controller|Subordinate Host Controller Post-Install]]
</blockquote>
 
==jboss.domain.master.port==
 
The port of the domain controller process.

Latest revision as of 14:05, 21 September 2017

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

System properties can be declared in standalone*.xml at the top of the file, conventionally right under the <extensions> element:

<server ...>
    <extensions>
       ...
    </extensions>

    <system-properties>
        <property name="a.system.property.available.to.the.server.instance" value="some value"/>
    </system-properties>
    ...
</server>

It seems that properties declared this way are not reported in server.log, at least not in EAP 7, under:

2017-03-27 09:51:02,353 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
        [Standalone] =
        awt.toolkit = sun.lwawt.macosx.LWCToolkit
        file.encoding = UTF-8
        file.encoding.pkg = sun.io
        ...

Domain Mode

System properties declared as described below are reported in server.log, at least not in EAP 7, unlike in standalone*.xml case.

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.

The fact that we are able to specify different properties (or same properties with different values) for different server groups allows us to use a single profile with multiple server groups, if the differences in configuration between server groups can be expressed as values of system properties. The following example shows how to declare different MDB container pool sizes for servers belonging to two different groups:

Using Same Profile but Different Configuration for Different Server Groups

Declaration in host.xml

System properties can be declared at the top of host.xml, right under the <extensions> element, applying to all servers on that host, as shown below:

<host ...>
    <extensions>
       ...
    </extensions>

    <system-properties>
        <property name="a.system.property.available.to.servers.on.this.host" value="some value/>
    </system-properties>
    ...
</domain>

or under <servers><server> elements, applying only to the specific servers they are declared for:

<host ...>
    ...
   <servers>
       <server name="A" group="red">
           <system-properties>
               <property name="a.system.property.available.to.serverA.only" value="something"/>
           </system-properties>
       </server>
   </servers>
</domain>

These properties are available to all servers executing on the host, and are not available to servers executed on other hosts.

System Property 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>
  ...

System Property Reference in Other System Properties

At least as per EAP 7, referring system properties from custom system properties declared in a <system-properties> block does not seem to work reliably: in the best case, properties are not replaced and left in the ${...} form, and in some cases, referring a property generates a configuration error:

2017-03-21 13:13:51,332 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0008: Failed to start server (app01): java.lang.IllegalStateException: WFLYCTL0211: Cannot resolve expression 'includes ${a.domain}'
...
Caused by: org.jboss.as.controller.OperationFailedException: WFLYCTL0211: Cannot resolve expression 'includes ${a.domain}' [ "WFLYCTL0211: Cannot resolve expression 'includes ${a.domain}'" ]
        at org.jboss.as.controller.ExpressionResolverImpl.parseAndResolve(ExpressionResolverImpl.java:282)
        at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionStringRecursively(ExpressionResolverImpl.java:142)
        at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:84)
        at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:66)

System Property Management with CLI

Manipulating System Properties

System Properties and Standard Paths

WildFly 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.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

Public Interface Configuration

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

Public Interface Configuration

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.private for Standalone Node

Define it as a system property at the bottom of $JBOSS_HOME/bin/standalone.conf:

...
JAVA_HOME="${JAVA_HOME} -Djboss.bind.address.private=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.private=192.168.1.10

jboss.bind.address.private 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.private=1.2.3.4"

The value propagates as system property to the process controller, host controller and servers.

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:

Subordinate Host Controller Post-Install

jboss.domain.master.port

The port of the domain controller process.