Configuring the domain.xml file
Recommended by 0 users
Configuring the domain
As we said, one of the main advantages of setting up a JBoss AS domain is to control and manage the server configurations and deployments from a single centralized point. The domain configuration consists mainly of two files, which are placed by default in the JBOSS_HOME\domain\configuration folder:
1. The domain.xml file describes the capabilities of your domain servers and defines the server groups that are part of the domain.
2. The host.xml file is present on each host where the domain is installed and specifies the elements that are specific to the servers running on the host.
Overriding the default configuration files
At any time, it’s possible to change the default configuration filenames and their path. By adding the following parameter to your domain shell, Windows users can define the new domain and host filename:
The equivalent for Linux users will be:
Note also that if you don’t provide any path, it’s assumed to be relative to the jboss.server.config.dir directory. Otherwise, it’s intended to be an absolute path.
Configuring the domain.xml file
The domain.xml contains the domain subsystems’ configuration that is shared by all servers in the domain. The content of the file follows the same structure of the standalone file, with an obvious and important difference. A domain can have several profiles defined in it. By default, two profiles are defined: a default profile and a ha profile, with the latter one to be used for clustered domains. You might, however, define your custom profile within it, such as a web profile or a messaging profile
Changing from one profile to another is the recommended way to expand or narrow the capabilities of the servers running in your domain.
Each AS domain can be further split into server groups, each one bound to a different profile. The concept of server groups can be seen as a set of servers managed as a single unit by the domain. You can actually use server groups for fine-grained configuration of nodes, for example, each server group is able to define its own settings, such as customized JVM settings, socket bindings interfaces, or deployed applications.
The following image illustrates some common attributes, which can be applied to a server group:
For example, here’s a richer server group definition bound to the default profile that provides to the servers which are part of it a deployed web application named sample.war, a customized JVM configuration, some system properties (which are loaded at boot time), and binds its services to the standard-sockets definition:
<server-group name=”custom-server-group” profile=”default”>
<deployment name=”sample.war_v1″ runtime-name=”sample.war”
<heap size=”512m” max-size=”1g”/>
<property name=”foo” value=”bar” boot-time=”true”/>
<property name=”key” value=”value” boot-time=”true”/>
Configuring the host.xml file
The other domain configuration file is named host.xml, which is well-placed in the JBOSS_HOME\domain\configuration folder. This file basically defines and configures the server nodes that are running on a host as part of a domain.
The term host here means a physical structure that is the portion of the domain which is contained in your AS distribution. Confused? Looking at the following image will make things clearer.
As you can see, a domain can contain several hosts (host1, host2) and also several groups (main server group, other server group). However, while a server group is simply a logical association of server nodes that can be located anywhere, a host refers to a set of nodes that are part of the same server distribution.
The term host can exactly match with the common meaning of machine , if you install one server distribution per machine. That’s not always true: as a matter of fact, you can also install several AS distributions on the same machine; thus you will have multiple hosts on the same machine.
Having completed our definition of hosts, we will look into the host configuration file,
which allows you to shape the following set of core domain elements:
- The management interfaces used to control the domain
- The domain controller definition
- The network interfaces where services are bound
- The defined JVMs configurations
- The servers that are part of the domain
In the next section, we will see each element of this file in detail and learn how to configure it appropriately.
Configuring the management interfaces
The management interface includes the definition of the native Command Line Interface (CLI) and http interface that are used to manage to the domain:
<socket interface=”management” port=”9999″/>
<socket interface=”management” port=”9990″/>
With the default configuration, both services will be bound to the management network interfaces. What distinguishes them is the native management interface, which is used by the CLI that will, by default, listen on port 9999, while the http administrative interface will listen on port 9990.
Configuring the network interfaces
We have just mentioned network interfaces. As you can guess from its name, a network interface refers to one or a set of network addresses. By default, the server contains two network interfaces definitions, which are named management and public respectively, and both of them are bound to the loopback address (127.0.0.1).
By changing the inet-address value of your network interface, you can configure the listening addresses of your application server. For example, if we want to bind the management interfaces to the loopback address (127.0.0.1) and the public interface to the address 192.168.1.1, you can simply use this configuration:
What this means in practice is that the management interfaces (the http admin console and the CLI) will be bound to the loopback address, while application-related services (bound to the public interface) will be bound to the IP address 192.168.1.1. . . . . .
<socket-binding-group name=”standard-sockets” defaultinterface=”
<socket-binding name=”http” port=”8080″/>
<socket-binding name=”https” port=”8443″/>
. . . . .