6 min read

This article by Francesco Marchioni author of the book Mastering JBoss Enterprise Application Platform 7dives deep into application server management using the domain mode, its main components, and discusses how to shift to advanced configurations that resemble real-world projects. Here are the main topics covered are:

  • Domain mode breakdown
  • Handy domainproperties
  • Electing the domaincontroller

(For more resources related to this topic, see here.)

Domain mode break down

Managing the application server in the domain mode means, in a nutshell, to control multiple servers from a centralized single point of control. The servers that are part of the domain can span across multiple machines (or even across the cloud) and they can be grouped with similar servers of the domain to share a common configuration. To make some rationale, we will break down the domain components into two main categories:

  • Physical components: Theseare the domain elements that can be identified with a Java process running on the operating system
  • Logical components: Theseare the domain elements which can span across several physical components

Domain physical components

When you start the application server through the domain.sh script, you will be able to identify the following processes:

  • Host controller: Each domain installation contains a host controller. This is a Java process that is in charge to start and stop the servers that are defined within the host.xml file. The host controller is only aware of the items that are specific to the local physical installation such as the domaincontroller host and port, the JVM settings of the servers or their system properties.
  • Domain controller: One host controller of the domain (and only one) is configured to act as domaincontroller. This means basically two things: keeping the domainconfiguration (into the domain.xml file) and assisting the host controller for managing the servers of the domain.
  • Servers: Each host controller can contain any number of servers which are the actual server instances. These server instances cannot be started autonomously. The host controller is in charge to start/stop single servers, when the domaincontroller commands them.

If you start the default domain configuration on a Linux machine, you will see that the following processes will show in your operating system:

As you can see, the process controller is identified by the [Process Controller] label, while the domaincontroller corresponds to the [Host Controller] label. Each server shows in the process table with the name defined in the host.xml file. You can use common operating system commands such as grep to further restrict the search to a specific process.

Domain logical components

A domain configuration with only physical elements in it would not add much to a line of standalone servers. The following components can abstract the domain definition, making it dynamic and flexible:

  • Server Group: A server group is a collection of servers. They are defined in the domain.xml file, hence they don’t have any reference to an actual host controller installation. You can use a server group to share configuration and deployments across a group of servers.
  • Profile: A profile is an EAP configuration. A domain can hold as many profiles as you need. Out of the box the following configurations are provided:
  • default: This configuration matches with the standalone.xml configuration (in standalone mode) hence it does not include JMS, IIOP, or HA.
  • full: This configuration matches with the standalone-full.xml configuration (in standalone mode) hence it includes JMS and OpenJDK IIOP to the default server.
  • ha: This configuration matches with the standalone-ha.xml configuration (in standalone mode) so it enhances the default configuration with clustering (HA).
  • full-ha: This configuration matches with the standalone-full-ha.xml configuration (in standalone mode), hence it includes JMS, IIOP, and HA.

Handy domainproperties

So far we have learnt the default configuration files used by JBoss EAP and the location where they are placed. These settings can be however varied by means of system properties. The following table shows how to customize the domain configuration file names:




The domain configuration file (default domain.xml)


The host configuration file (default host.xml)    

On the other hand, this table summarizes the available options to adjust the domain directory structure:




The base directory for domain content


The base configuration directory


The directory used for persistent data file storage


The directory containing the host-controller.log and process-controller.log files


The directory used for temporary file storage


The directory used to store deployed content


The directory containing the managed server instances

For example, you can start EAP 7 in domain mode using the domain configuration file mydomain.xml and the host file named myhost.xml based on the base directory /home/jboss/eap7domain using the following command:

$ ./domain.sh –domain-config=mydomain.xml –host-config=myhost.xml –Djboss.domain.base.dir=/home/jboss/eap7domain

Electing the domaincontroller

Before creating your first domain, we will learn more in detail the process which connects one or more host controller to one domaincontroller and how to elect a host controller to be a domaincontroller.

The physical topology of the domain is stored in the host.xml file. Within this file, you will find as the first line the Host Controller name, which makes each host controller unique:

One of the host controllers will be configured to act as a domaincontroller. This is done in the domain-controller section with the following block, which states that the domaincontroller is the host controller itself (hence, local):

All other host controllers will connect to the domaincontroller, using the following example configuration which uses the jboss.domain.master.address and jboss.domain.master.port properties to specify the domaincontroller address and port:

The host controller-domaincontroller communication happens behind the scenes through a management native port that is defined as well into the host.xml file:

The other highlighted attribute is the managementhttpport that can be used by the administrator to reach the domaincontroller. This port is especially relevant if the host controller is the domaincontroller. Both sockets use the management interface, which is defined in the interfaces section of the host.xml file, and exposes the domain controller on a network available address:

If you want to run multiplehost controllers on the same machine, you need to provide a unique jboss.management.native.port for each host controller or a different jboss.bind.address.management.


In this article we have some essentials of the domain mode breakdown, handy domain propertiesand also electing the domain controller.

Resources for Article:

Further resources on this subject:

Subscribe to the weekly Packt Hub newsletter

* indicates required


Please enter your comment!
Please enter your name here