The first one we will detail is also the simplest, which merely requires unzipping a file. The JBoss EAP 7 ZIP file is available from the Red Hat Customer Portal. This method of installation is platform-independent and requires the following steps:

JBoss EAP 7 is now downloaded to your target machine, ready for installation. Execute the following command in order to unzip the archive:

unzip jboss-eap-7.0.0.zip

Now you can test that the installation was successful by executing the standalone.sh shell script (Windows users will launch the standalone.cmd equivalent).

cd jboss-eap-7.0
cd bin
$ ./standalone.sh

This method of installation is peculiar of JBoss EAP and can be a practical solution if you want to manage your application ecosystem through Red Hat Packet Manager (RPM) archives.

Installing JBoss EAP 7 via RPM requires a subscription to the official Red Hat's repositories. You can either subscribe to the current JBoss EAP channel or a minor channel that provides a specific minor release and all applicable patches. This allows you to maintain the same minor version of JBoss EAP 7, while still staying current with high severity and security patches.

Let's see in practice how the installation can be done on a RHEL 7 operating system. First of all, we have to register our brand new server to the Red Hat Network (RHN), using our credentials (username/password) for accessing to all needed subscriptions.

The command will ask for username or password, or in case we've planned to use an internal RH Satellite 6 system, we can use a preconfigured Activation Key as an option:

# subscription-manager register

After a successful registration we need to figure out to which Pool we need to attach for downloading the EAP 7 packages. We can use the subscription-manager list command followed by the less one for searching through multiple subscriptions:

# subscription-manager list --available|less
Subscription Name:   Client SKU
Provides:            Oracle Java (for RHEL Server) - AUS
                     Oracle Java (for RHEL Client)
                     Red Hat Enterprise Linux 7 High
                         Availability 
                     Red Hat Enterprise Linux High Availability                      
                     Red Hat EUCJP Support (for RHEL Server)
                     Red Hat Enterprise Linux for Power 
                     Red Hat Enterprise Linux EUS Compute Node
                     Red Hat Enterprise Linux for Power, big
                         endian - 
                     Red Hat OpenShift Enterprise JBoss EAP 
                         add-on
                     Oracle Java (for RHEL Server) - Extended 
                         Update 
                     dotNET on RHEL Beta (for RHEL Server)
                     Red Hat Enterprise Linux Load Balancer 
                     JBoss Enterprise Web Server
                     JBoss Enterprise Application Platform -
                         ELS
                     . . . . . . . . . . . . . . . . . . .

As soon as we find the right subscription (you should choose something like: JBoss Enterprise Application Platform) we have to take note of the pool ID and run the following:

# subscription-manager attach --pool 
    844aff014485be8a85f8d058bf198144

After that we can explore the available repositories:

# subscription-manager repos --list

We won't list here all the available repositories which is quite large; however, you have to enable only EAP, RHEL7 base rpms, extras, and optional repository, and disable all the others with the following command:

# subscription-manager repos --disable="*" --enable jb-eap-7.0-
    for-rhel-7-server-rpms --enable rhel-7-server-rpms --enable 
    rhel-7-server-extras-rpms --enable rhel-7-server-optional-rpms

You can verify that the process worked as expected by simply running the following:

# yum repolist

The list should look like this:

Loaded plugins: search-disabled-repos
repo id                                                                      
    name                                                                                    
!jb-eap-7.0-for-rhel-7-server-rpms/7Server/x86_64 (RPMs)
!rhel-7-server-extras-rpms/x86_64                 (RPMs)
!rhel-7-server-optional-rpms/7Server/x86_64       (RPMs)
!rhel-7-server-rpms/7Server/x86_64                (RPMs)
repolist: 19,727

Complete the installation by executing the following:

# yum groupinstall jboss-eap7

The JBoss EAP 7 installer archive is also available from the Red Hat Customer Portal (https://access.redhat.com). The .jar archive can be used to run either the graphical or text-based installers.

In order to complete the JAR installation, follow these steps:

java -jar jboss-eap-7.0.0-installer.jar -console

We will not detail the single steps of the installation which are quite intuitive and covered by the EAP installation guide. Rather we would like to stress that the installer produces an XML script; you can reuse it for multiple installations, as you can see from the following picture:

If you open the generated XML file, then you can pinpoint some custom elements in the installation:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
<AutomatedInstallation langpack="eng"> 
<productName>EAP</productName> 
<productVersion>7.0.0</productVersion> 
<com.izforge.izpack.panels.HTMLLicencePanel id="HTMLLicencePanel"/> 
<com.izforge.izpack.panels.TargetPanel id="DirectoryPanel"> 
<installpath>/home/francesco/EAP-7.0.0</installpath> 
. . . . . 
</AutomatedInstallation> 

Then you can repeat the installation with the following command:

java -jar jboss-eap-7.0.0-installer.jar -xml yourxml

Downloading the source code can be used if you need low-level details about the single modules of the application server. Once you have downloaded the jboss-eap-7.0.0-src.zip file, unzip it to your disk at first. Next you can build the server in two ways:

$ mvn install

Change to the bin directory after a successful build:

$ cd build/target/jboss-eap/bin

Verify that the application server boots successfully:

$ ./standalone.sh

The amount of installation options for EAP could well deserve one or more chapters; however, that would take us away from the scope of this book. We will just mention Ansible, which is an excellent configuration management and provisioning tool that uses SSH to perform administrative tasks on your machines. This has the evident advantage that nothing needs to be installed on the machines you are targeting as Ansible only runs on your main control machine, which could even be your laptop!

The steps used by Ansible to provision and configure machines are described in a kind of template called Playbooks, which are Ansible's configuration, deployment, and orchestration language.

You can find a large list of example Playbooks in the Ansible documentation, available at http://docs.ansible.com/ansible . Besides this, for testing purposes we have provided a sample EAP 7 playbook which is attached to the sources of this book. (Read the instructions contained in the README.txt file packaged in ansible.zip.)

Besides this, if you want a user interface for your provisioning activities, Ansible Tower is a web-based solution that makes Ansible even more easy to use for IT teams of all kinds. It's designed to be the hub for all of your automation tasks.

A standalone server is an independent server process which uses a single configuration file. The configuration, by default, is stored in the JBOSS_HOME/standalone/configuration folder. Within this directory, some built-in configurations are available. Here is a short description of them:

If you want to start a non-default configuration, then you can use the -c parameter. Here's, for example, how to start the server using the ha server configuration:

$ ./standalone.sh -c standalone-ha.xml 

When running in domain mode the configuration is maintained in a single file named domain.xml that resides on the domain controller. This file contains a set of profiles, each one corresponding to the configuration seen earlier in the standalone mode, so you will be able to find the following XML structure within it:

<profiles> 
        <profile name="default">. . .</profile> 
        <profile name="ha"> . . . </profile> 
        <profile name="full"> . . .</profile> 
        <profile name="full-ha">. . .</profile> 
</profiles> 

Each domain is logically divided into server groups that contain the single server instances. The server groups are bound to the profiles described so far:

<server-groups> 
        <server-group name="main-server-group" profile="full"> 
            <socket-binding-group ref="full-sockets"/> 
        </server-group> 
        <server-group name="other-server-group" profile="full-ha"> 
            <socket-binding-group ref="full-ha-sockets"/> 
        </server-group> 
</server-groups> 

The single server instances are defined in the host.xml file that is included in every host controller. Within this file you will find the list of servers that will be available on that host:

<servers> 
      <server name="server-one" group="main-server-group"> 
      </server> 
      <server name="server-two" group="main-server-group"
      auto-start="true"> 
            <socket-bindings port-offset="150"/> 
      </server> 
      <server name="server-three" group="other-server-group" 
      auto-start="false"> 
            <socket-bindings port-offset="250"/> 
      </server> 
</servers> 

We will discuss more in detail about the domain core components in Chapter 3, Managing EAP in Domain Mode, of this book. Whatever your server mode, a number of common configuration concepts apply; in the next sections of this chapter we will describe them.

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.