Every Java library that is installed into the application server is called a module. An extension is a special kind of module that is strictly bound to the application server life cycle and is managed through the core server configuration. The configuration of the extension, if any, is declared in a subsystem section. Here is an excerpt of the server configuration which declares a set of extensions (such as the logging extension), that is later configured through the logging subsystem:

<server xmlns="urn:jboss:domain:4.1"> 
    <extensions> 
        <extension module="org.jboss.as.clustering.infinispan"/> 
        <extension module="org.jboss.as.connector"/> 
        <extension module="org.jboss.as.deployment-scanner"/> 
        <extension module="org.jboss.as.ee"/> 
        <extension module="org.jboss.as.ejb3"/> 
        <extension module="org.jboss.as.jsf"/> 
        <extension module="org.jboss.as.logging"/> 
        . . . . . 
    </extensions> 
    . . . . . 
    <profile> 
        <subsystem xmlns="urn:jboss:domain:logging:3.0"> 
    . . . . . 
    </profile> 
</server> 

The path is a logical name for a filesystem path. You can declare a path element in your configuration so that you can reference them using a logical unit, instead of the physical one which may vary on different machines. Out of the box, for example, the logging subsystem includes a reference to the jboss.server.log.dir path.

This in turn points to the server's log directory:

<file relative-to="jboss.server.log.dir" path="server.log"/> 

Although you will not find them in the default configuration, some standard paths are available with the application server. Here is a list of them:

Here is an example of a custom path definition:

[standalone@localhost:9990 /] /path=secure:add(path=securedata,relative-to=jboss.server.data.dir)

This will generate the following output in the server's configuration:

<path name="secure" path="securedata" relative-to="jboss.server.data.dir"/> 

The attributes of the path element are as follows:

An interface is a logical name for a network interface / hostname / IP address to which the application server sockets can be bound. The server configuration includes a section where the interfaces are declared. Other parts of the configuration will reference the network interfaces so that you can specify the bindings for the single services.

The most relevant entries in the interfaces section are the management and public interfaces:

<interface name="management"> 
   <inet-address   value="${jboss.bind.address.management:127.0.0.1}"/> 
</interface> 
<interface name="public"> 
  <inet-address value="${jboss.bind.address:127.0.0.1}"/> 
</interface> 

As you can guess, the management interface defines the bindings for the administration instruments like the CLI and the web interface. The public interface relates to application-related services like HTTP, HTTPS, AJP, and so on.

The value of an interface is typically exposed using a BeanShell expression which contains in the left section the binding (also as a system property) and optionally in the right side a default value for it, separated by a colon ( :).

/interface=public/:write-attribute(name=inet-address,
value=${jboss.bind.address:192.168.10.1})
{
    "outcome" => "success",
    "response-headers" => {
       "operation-requires-reload" => true,
       "process-state" => "reload-required"
    }
}

The preceding command needs a reload of the server configuration to propagate changes, hence the need to issue the reload command afterwards:

[standalone@localhost:9990 /] reload

That being said, the best practice for setting interface attributes is by means of system properties; this way you will not introduce any dependency against your environment.

Here is, for example, how you can start the standalone server binding the management interfaces and public interfaces to the loopback address:

./standalone.sh -Djboss.bind.address.management=192.168.10.1 -           
Djboss.bind.address=127.0.0.1  

A socket binding is a named configuration for a socket. Both the domain.xml and standalone.xml configurations include a section where socket configurations can be declared. Other parts of the configuration can then reference those sockets by their logical name, rather than having to include details of the actual socket configuration.

This is an excerpt from the default socket bindings in standalone mode:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> 
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> 
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/> 
        <socket-binding name="ajp" port="8009"/> 
        <socket-binding name="http" port="8080"/> 
        <socket-binding name="https" port="8443"/> 
        <outbound-socket-binding name="mail-smtp"> 
            <remote-destination host="localhost" port="25"/> 
        </outbound-socket-binding> 
</socket-binding-group> 

Just like the network interfaces, it is a good practice to vary them using shell parameters. This is how you can set a port offset of 100 at startup:

./standalone.sh -Djboss.socket.binding.port-offset=100  

System property values can be used to customize some aspects of the server configuration. When running in the standalone mode, the properties set in standalone.xml will be part of the server boot process.

For example, the following property named org.apache.cxf.logging.enabled can be used to set the enable logging of web services deployed on the application server:

<system-properties> 
  <property name="org.apache.cxf.logging.enabled" value="true"/> 
</system-properties> 

You can achieve this result through the CLI with the following command:

[standalone@localhost:9990 /] /system-property=                    
org.apache.cxf.logging.enabled:add(value=true)
{"outcome" => "success"}

You can conversely read the property using the read-resource command:

[standalone@localhost:9999 /] /system-property=      
org.apache.cxf.logging.enabled:read-resource {     "outcome" =>   
"success",     "result" => {"value" => "true"} }

When running in the domain mode, properties can be set at different levels. We will discuss this in more detail in Chapter 3, Managing EAP in Domain Mode, of this book, which is about the domain mode.

The most significant part of the server configuration is about defining one (in standalone.xml) or more (in domain.xml) profiles. A profile is nothing but a named set of subsystem configurations. A subsystem in turn is a set of services added to the core server by means of extensions.

For example, the following fragment is an example of a subsystem which controls the capabilities of the JPA server implementation:

  <subsystem xmlns="urn:jboss:domain:jpa:1.1"> 
      <jpa default-datasource="" default-extended-   
       persistence-inheritance="DEEP"/> 
  </subsystem> 

The content of an individual profile configuration looks largely the same in the domain mode and in the standalone mode. The main difference is that in the standalone mode the standalone.xml file is only allowed to have a single profile element (the profile the server will run), whereas in the domain mode the domain.xml file can have many profiles, each of which can be mapped to one or more groups of servers.

There are two main instruments for managing the subsystems of the application server. The basic approach is to use the web console that is available by default on the port 9990 of the management interface (hence, the default is http://localhost:9990).

Once logged in with the management user, you can navigate through the Configuration upper tab and choose the subsystem you want to edit by clicking on its View button, as depicted by the following picture:

Although pretty simple and powerful, across this book we will use the CLI as the main configuration tool. The CLI is apparently more complex but it offers many advantages such as batch execution of commands in scripts, parameterization of the attributes to be used in scripts, and consistency between different server releases, to mention just a few.