Red Hat JBoss Enterprise Application Platform Administration I

The domain controller settings are found in two locations:

The settings from both files are combined to configure and create the domain controller. The domain.xml file contains the same structure as the standalone.xml file, with some differences. These differences are described below:

The domain.xml file is structured as follows:

<domain xmlns="urn:jboss:domain:16.0">
  <extensions>
    ... domain controller extensions
  </extensions>
  <system-properties>
    ... for defining system properties
  </system-properties>
  <paths>
    ... for defining filesystem paths
  </paths>
  <management>
    ... the management interfaces and their security settings appear here
  </management>
  <profiles>
    <profile name="profile_name">
      <subsystem xmlns="subsystem_xmlns">
            ... Configuration from subsystems
      </subsystem>
    </profile>
  </profiles>
  <interfaces>
    ... interfaces are defined here
  </interfaces>
  <socket-binding-groups>
    ... Socket binding groups configuration are defined here
  </socket-binding-groups>
  <deployments>
    ... deployments are defined here
  </deployments>
  <server-groups>
    ... server groups are defined here
  </server-groups>
</domain>

Notice that profiles are defined within the <profiles> section, and each <profile> must have a unique name.

The <server-groups> section is for defining and grouping servers, something that is not possible in standalone mode. Servers and server groups are discussed later in this course.

Both domain.xml and host.xml use a collection of XML tags to specify their configuration options. Some of these tags show in both files. The following table describes which tags show in which file.

Figure 4.8: XML structure comparison

Deployed applications of a domain are configured in the domain.xml domain controller configuration file. If the application is present in the domain, then you can assign it to a server group. Adding an enterprise application archive (EAR) file, or a web application archive (WAR) file in the <deployments> section makes that application available for deployment to a server group.

A <path> defined in domain.xml does not actually have a value, only a name. The actual value is defined in host.xml. This enables variables to be defined at the domain level, but allows each host to have a unique value for that variable. This is extremely useful because hosts might not be running the same operating systems or might have files deployed in entirely different locations.

An <interface> definition is similar to a <path> in the domain.xml file. When configuring the interfaces of a domain, the domain controller does not need to know the specific addresses of each host. Thus, the <interface> element in domain.xml acts as a placeholder that is overridden in the host.xml file of the host controller.

For example, only the name of the interface is defined in domain.xml:

<interface name="my_interface"/>

Continuing the example, the actual IP address or device name for the interface is specified in host.xml:

<interface name="my_interface">
    <nic name="eth1"/>
</interface>

Each server is managed by the host controller and not by the domain controller and each server is declared as part of the host.xml configuration file.

Notice that <server-groups> is defined at the domain level, but <servers> is defined at the host level. This means that the domain.xml and host.xml files need to be compatible with each other, because a <server> definition in host.xml must refer to a <server-group> definition in domain.xml. If a <server> definition in host.xml refers to a <server-group> that is not defined in domain.xml, then the host controller does not start.

Notice also that <deployments> is defined at the domain level, not the host level. It is not possible to deploy applications onto servers. They should be deployed onto server groups.

In JBoss EAP it is possible to define <extensions> in the host.xml file to support subsystems running on specific hosts.

The way to navigate in domain mode with the management CLI is different from standalone mode. There are new resources available at the top level:

[domain@172.25.250.254:9990 /] cd

Using tab completion, the following levels are returned:

--help                     extension                  profile
--no-validation            host                       server-group
core-service               interface                  socket-binding-group
deployment                 management-client-content  system-property
deployment-overlay         path

The first difference is the host level. This level lists all host controllers managed by the domain:

[domain@172.25.250.9:9990 /] cd host
[domain@172.25.250.9:9990 host] ls
host2   host3   master

The host level is used to manage and get runtime metrics from the available hosts. For example,you can add a new server to the host3 host:

[domain@172.25.250.9:9990 /] cd /host=host2/server-config
[domain@172.25.250.9:9990 server-config] ./server-c:add\
(auto-start=true, group=main-server-group)

To remove a server, use the remove operation:

[domain@172.25.250.9:9990 /] /host=host2/server-config/server-c:\
remove()

Another important item on the host level is the ability to get runtime information. For example, to get memory runtime metrics from a server, use the following commands:

[domain@172.25.250.9:9990 /] cd /host=host2/server=server-one/
[domain@172.25.250.9:9990 server=server-one] cd core-service=platform-mbean/
[domain@172.25.250.9:9990 core-service=platform-mbean] ./type=memory:\
read-attribute(name=heap-memory-usage)

A similar output is expected:

{
    "outcome" => "success",
    "result" => {
        "init" => 67108864L,
        "used" => 126501384L,
        "committed" => 206045184L,
        "max" => 477626368L
    }
}

The top level also provides the server-group level. This level is responsible for creating and managing the server groups. To create a new group, use the following command:

[domain@172.25.250.9:9990 core-service=platform-mbean] cd /
[domain@172.25.250.9:9990 /] /server-group=production:add\
(profile=ha,socket-binding-group=ha-sockets)

To remove the production server group, use the remove operation:

[domain@172.25.250.9:9990 /] /server-group=production:remove()

To remove a server-two server from a serverb host controller, use the following operation:

[domain@172.25.250.9:9990 /] /host=serverb/server-config=server-two:remove()

To configure or manage a subsystem, it is required to first navigate to the desired named profile:

[domain@172.25.250.9:9990 /] cd /profile=ha/subsystem=ejb3

The socket-binding-group level is responsible for configuring the available sockets for use by the server groups.

The :take-snapshot operation is available to backup the domain.xml configurations. This operation generates a backup file in the JBOSS_HOME/domain/configuration/domain_xml_history/snapshot directory:

[domain@172.25.250.9:9990 /] :take-snapshot