JB348 Red Hat JBoss Application Administration II

RED HAT®
TRAINING
Comprehensive, hands-on training that solves real world problems
Red Hat JBoss Application

Administration II
Student Workbook (ROLE)
© 2017 Red Hat, Inc. JB348-RHJBEAP7-en-6-20170411

RED HAT JBOSS
APPLICATION
ADMINISTRATION II
Red Hat JBoss Application Administration II
Red Hat JBoss Enterprise Application Platform 7 JB348

Edition 6 20170411
Authors: Douglas Silva, Jim Rigsbee, Zachary Gutterman

Editor: David Sacco
Copyright © 2017 Red Hat, Inc.
The contents of this course and all its modules and related materials, including handouts to
audience members, are Copyright © 2017 Red Hat, Inc.
No part of this publication may be stored in a retrieval system, transmitted or reproduced in

any way, including, but not limited to, photocopy, photograph, magnetic, electronic or other
record, without the prior written permission of Red Hat, Inc.
This instructional program, including all material provided herein, is supplied without any
guarantees from Red Hat, Inc. Red Hat, Inc. assumes no liability for damages or legal action
arising from the use or misuse of contents or details contained herein.
If you believe Red Hat training materials are being used, copied, or otherwise improperly
distributed please e-mail training@redhat.com or phone toll-free (USA) +1 (866) 626-2994
or +1 (919) 754-3700.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, Hibernate, Fedora, the
Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and
other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other
countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a registered trademark of Silicon Graphics International Corp. or its subsidiaries in

the United States and/or other countries.
The OpenStack® Word Mark and OpenStack Logo are either registered trademarks/service
marks or trademarks/service marks of the OpenStack Foundation, in the United States
and other countries and are used with the OpenStack Foundation's permission. We are not
affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack
community.
All other trademarks are the property of their respective owners.
Contributors: Ricardo Jun, Heather Charles, Seth Kenlon, Scott McBrien, George Hacker
Document Conventions ix
Notes and Warnings ................................................................................................ ix
Introduction xi
Red Hat JBoss Application Administration II ............................................................... xi
Structure of the Course .......................................................................................... xii
Orientation to the Classroom Lab Environment ......................................................... xiii
Internationalization ................................................................................................. xv
1. What's New in JBoss EAP 7? 1

Identifying the New Specifications in Java EE 7 .......................................................... 2
Quiz: What's New in JBoss EAP 7 .............................................................................. 4
Configuring EAP with the New Management Console ................................................... 6
Guided Exercise: Configuring EAP with the New Management Console ........................... 8
Identifying New Features in JBoss EAP 7 ................................................................... 11
Quiz: What's New in JBoss EAP 7 ............................................................................. 14
Lab: What's New in JBoss EAP 7? ............................................................................ 16
Summary ............................................................................................................... 21
2. Migrating to JBoss EAP 7 23

Migrating JBoss EAP 6 Applications to JBoss EAP 7 .................................................. 24
Quiz: Migrating Applications to JBoss EAP 7 ............................................................. 27
Generating a Windup Report ................................................................................... 29
Guided Exercise: Analyzing a Migration with Windup .................................................. 32
Planning a Migration with JBoss Server Migration Tool .............................................. 35
Guided Exercise: Migration with JBoss Server Migration Tool ...................................... 37
Lab: Migrating to JBoss EAP 7 ................................................................................. 41
Summary .............................................................................................................. 48
3. Configuring a JBoss EAP Cluster 49

Reviewing Clustering Concepts ................................................................................ 50
Guided Exercise: Creating a Cluster ......................................................................... 52
Exploring Infinispan ................................................................................................ 59
Guided Exercise: Tuning Infinispan ........................................................................... 65
Exploring JGroups ................................................................................................. 69
Guided Exercise: Troubleshooting JGroups ................................................................ 74
Deploying HA Singleton Applications ........................................................................ 81
Guided Exercise: Deploying an HA Singleton ............................................................. 84
Lab: Configuring a JBoss EAP Cluster ...................................................................... 88
Summary ............................................................................................................. 106
4. Deploying Applications 107

Installing EAP with Advanced Options ..................................................................... 108
Quiz: Running EAP as a Service on RHEL ................................................................. 112
Understanding Rolling Upgrades .............................................................................. 114
Guided Exercise: Performing a Rolling Update ........................................................... 118
Deploying Applications in the Cloud ........................................................................ 122
Quiz: Migrating Applications to JBoss EAP 7 ............................................................ 128
Lab: Deploying Applications ................................................................................... 130
Summary .............................................................................................................. 137
5. Configuration and Management Scripting with CLI 139

Scripting with the JBoss EAP CLI ........................................................................... 140
Guided Exercise: Using the CLI Shell ....................................................................... 145
JB348-RHJBEAP7-en-6-20170411 v
Reviewing Configuration and Management Examples ................................................ 149

Guided Exercise: Creating a CLI Script ..................................................................... 151
Scripting Common Tasks ........................................................................................ 155
Guided Exercise: Common Task Scripts .................................................................... 161
Lab: Configuration and Management Scripting with CLI ............................................ 166
Summary .............................................................................................................. 173
6. Monitoring and Management 175

Describing the Features of the EAP Management Console ......................................... 176
Guided Exercise: Changing Logging Levels ............................................................... 179
Defining the Features of the Management API ......................................................... 182
Guided Exercise: Exploring the Management API ...................................................... 192
Utilizing the Native Management API ...................................................................... 195
Quiz: Native Management API ................................................................................ 198
Configuring Custom Services with JMX .................................................................. 200
Guided Exercise: Custom Services with JMX ........................................................... 204
Lab: Monitoring and Management .......................................................................... 207
Summary ............................................................................................................. 214
7. Configuring and Tuning the Messaging System 215

Configuring the Features of ActiveMQ Artemis ......................................................... 216
Guided Exercise: Configuring the Features of ActiveMQ Artemis ................................ 224
Configuring Message Persistence with ActiveMQ Artemis ......................................... 229
Guided Exercise: Configuring Message Persistence with ActiveMQ Artemis ................. 234
Configuring Messaging Bridges .............................................................................. 239
Guided Exercise: Configuring Messaging Bridges ..................................................... 242
Configuring the Messaging Cluster for High Availability ............................................ 246
Guided Exercise: Configuring the Messaging Cluster ................................................ 249
Tuning Messaging Performance ............................................................................. 253
Guided Exercise: Configuring and Tuning the Messaging System ................................ 257
Lab: Messaging System Configuration and Tuning .................................................... 260
Summary ............................................................................................................. 267
8. Securing Applications 269

Securing Applications ........................................................................................... 270
Guided Exercise: Securing an Application ................................................................ 274
Defining Role Based Access Control ....................................................................... 280
Guided Exercise: Defining Role Based Access Control ............................................... 283
Securing Applications with Red Hat Identity Management ........................................ 287
Guided Exercise: Secure Applications with SSO ....................................................... 290
Lab: Securing Applications .................................................................................... 296
Summary ............................................................................................................ 306
9. Securing EAP 307

Securing EAP ...................................................................................................... 308
Guided Exercise: Working with add-user.sh .......................................................... 312
Securing the Management Interface ........................................................................ 315
Guided Exercise: Implementing Role-based Security for the Management Interface ....... 318
Configuring Management Audit Logging ................................................................. 322
Guided Exercise: Enabling Management Audit Logging ............................................. 325
Deploying Patches to EAP ..................................................................................... 328
Guided Exercise: Installing a Patch ......................................................................... 330
Configuring Messaging Security ............................................................................. 333
vi JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Configuring Messaging Security ..................................................... 336
Lab: Securing EAP ............................................................................................... 340
Summary ............................................................................................................. 347
10. Comprehensive Review: Red Hat JBoss Application Administration II 349
Comprehensive Review ........................................................................................ 350
Lab: Comprehensive Review Part One ..................................................................... 351
Lab: Comprehensive Review Part Two .................................................................... 365
Lab: Comprehensive Review Part Three .................................................................. 373
Summary ............................................................................................................ 380
JB348-RHJBEAP7-en-6-20170411 vii
viii
Document Conventions
Notes and Warnings
Note
"Notes" are tips, shortcuts or alternative approaches to the task at hand. Ignoring a
note should have no negative consequences, but you might miss out on a trick that
makes your life easier.
Important
"Important" boxes detail things that are easily missed: configuration changes that
only apply to the current session, or services that need restarting before an update
will apply. Ignoring a box labeled "Important" will not cause data loss, but may cause
irritation and frustration.
Warning
"Warnings" should not be ignored. Ignoring warnings will most likely cause data loss.
References
"References" describe where to find external documentation relevant to a subject.
JB348-RHJBEAP7-en-6-20170411 ix
x
Introduction
Red Hat JBoss Application Administration II: JB348 prepares experienced System Administrators
to provision and manage JBoss EAP in large-scale production environments. This course
takes a deeper dive into provisioning EAP instances, clustering, and domain management
through CLI scripting, clustering, and tuning of the ActiveMQ Artemis messaging system is
covered. This course also takes a deeper dive into the security systems of EAP including the
management interface, securing resources such as JMS queues, Kerberos integration, and
network considerations.
Objectives
JB348 is intended to give experienced administrators a deeper understanding of how to
work with EAP 7.0 by taking a closer look at clustering, deployments, scripting, management,
messaging, and security with a view towards building on the skills established in Red Hat JBoss
Application Administration I (JB248). The course places a particular focus on automating tasks
using the new Command Line Interface (CLI) features of EAP 7.0.
Audience
• Experienced System Administrators responsible for deploying and administering JBoss EAP 7
in large-scale production environments.
• At least 2 years as a JBoss EAP Administrator.
• RHCJA EAP 7 certified administrator (recommended).
Prerequisites
Students should meet one or more of the following prerequisites:
• Highly Recommended: Attend Red Hat JBoss Application Administration I (JB248)
• Be a Red Hat Certified JBoss Administrator (EAP 7), or at least familiar with the tasks
associated with the RHCJA EAP certification
JB348-RHJBEAP7-en-6-20170411 xi
Introduction
Structure of the Course

Red Hat training courses are interactive, hands-on, performance-based, real world classes meant
to engage your mind and give you an opportunity to use real systems to develop real skills. We
encourage students to participate in class and ask questions in order to get the most out of their
training sessions.
This course is divided up into a number of Chapters organized around a particular topic area.
Each Chapter is divided up into multiple Sections which focus on a specific skill or task. The
chapter will start with an introduction to the material, then move on to the first section.
In each section, there will be a presentation led by the instructor. During the presentation, it may
be a good idea to take notes in your student workbook (this book), and the instructor may remind
you to do so. The presentation is followed by a short activity or assessment to give you the
opportunity to practice with the material or review procedures. After a review of the assessment,
the instructor will move on to the next section. At the end of the chapter, there will normally be a
hands-on lab exercise of some sort (a "criterion test") which will give you an opportunity to learn
by doing and review your understanding of the chapter's content. Please feel free ask questions
in class, or asking the instructor for advice and help during the end-of-chapter exercise. We want
the classroom environment to be a "low risk" place where you feel comfortable asking questions
and learning from things that work and things that do not at first.
xii JB348-RHJBEAP7-en-6-20170411
Orientation to the Classroom Lab Environment
Orientation to the Classroom Lab Environment

In this course, students will do most hands-on practice exercises and lab work with a computer
system, which will be referred to as workstation. This machine has the host name station
workstation.lab.example.com. The machine has a standard user account, student, with
the password student. Access to the root account is available from the student account, using the
sudo command.
Students have two more VMs called servera and serverb that will be used to create additional
EAP server instances. The classroom utility server is password-protected from the students and
shared by all them.
Most activities use the lab command, executed on workstation, to prepare and evaluate the
exercise. lab takes two arguments: the activity's name and a verb of setup, grade, reset,
cleanup, or solve.
• The setup verb is used at the beginning of an exercise. It will verify that the systems are ready
for the activity, possibly making some configuration changes to them.
• The grade verb is executed at the end of an exercise. It provides external confirmation that
the activity's requested steps were performed correctly.
• The reset verb can be used to turn back the clock and start the activity over again, usually
followed by setup.
• The optional cleanup verb can be used to selectively undo elements of the activity before
moving on to later activities.
In a Red Hat Online Learning classroom, students will be assigned remote computers which will
be accessed through a web application hosted at rol.redhat.com. Students should log into this
machine using the user credentials they provided when registering for the class.
Each student is on the IPv4 network 172.25.X.0/24, where the X matches the number of their
station system. The instructor runs a central utility server, classroom, which acts as a router
for the classroom networks and provides DNS, DHCP, HTTP, and other content services.
Classroom Machines
Machine name IP addresses Role
stationX.example.com 172.25.X.9 Student computer
classroom.example.com 172.25.254.254 Classroom utility server
Controlling your station

The top of the console describes the state of your machine.
Machine States
State Description
none Your machine has not yet been started. When started, your machine
will boot into a newly initialized state (the desk will have been reset).
starting Your machine is in the process of booting.
running Your machine is running and available (or, when booting, soon will be.)
JB348-RHJBEAP7-en-6-20170411 xiii
Introduction
State Description
stopping Your machine is in the process of shutting down.
stopped Your machine is completely shut down. Upon starting, your machine
will boot into the same state as when it was shut down (the disk will
have been preserved).
impaired A network connection to your machine cannot be made. Typically this
state is reached when a student has corrupted networking or firewall
rules. If the condition persists after a machine reset, or is intermittent,
please open a support case.
Depending on the state of your machine, a selection of the following actions will be available to
you.
Machine Actions
Action Description
Start Station Start ("power on") the machine.
Stop Station Stop ("power off") the machine, preserving the contents of its disk.
Reset Station Stop ("power off") the machine, resetting the disk to its initial state.
Caution: Any work generated on the disk will be lost.
Refresh Refresh the page will re-probe the machine state.
Increase Timer Adds 15 minutes to the timer for each click.
The station timer

Your Red Hat Online Learning enrollment entitles you to a certain amount of computer time. In
order to help you conserve your time, the machines have an associated timer, which is initialized
to 60 minutes when your machine is started.
The timer operates as a "dead man’s switch," which decrements as your machine is running. If
the timer is winding down to 0, you may choose to increase the timer.
xiv JB348-RHJBEAP7-en-6-20170411
Internationalization
Internationalization
Language support
Red Hat Enterprise Linux 7 officially supports 22 languages: English, Assamese, Bengali, Chinese
(Simplified), Chinese (Traditional), French, German, Gujarati, Hindi, Italian, Japanese, Kannada,
Korean, Malayalam, Marathi, Odia, Portuguese (Brazilian), Punjabi, Russian, Spanish, Tamil, and
Telugu.
Per-user language selection

Users may prefer to use a different language for their desktop environment than the system-
wide default. They may also want to set their account to use a different keyboard layout or input
method.
Language settings
In the GNOME desktop environment, the user may be prompted to set their preferred language
and input method on first login. If not, then the easiest way for an individual user to adjust their
preferred language and input method settings is to use the Region & Language application. Run
the command gnome-control-center region, or from the top bar, select (User) > Settings.
In the window that opens, select Region & Language. The user can click the Language box and
select their preferred language from the list that appears. This will also update the Formats
setting to the default for that language. The next time the user logs in, these changes will take
full effect.
These settings affect the GNOME desktop environment and any applications, including gnome-
terminal, started inside it. However, they do not apply to that account if accessed through an
ssh login from a remote system or a local text console (such as tty2).
Note
A user can make their shell environment use the same LANG setting as their graphical
environment, even when they log in through a text console or over ssh. One way to do
this is to place code similar to the following in the user's ~/.bashrc file. This example
code will set the language used on a text login to match the one currently set for the
user's GNOME desktop environment:
i=$(grep 'Language=' /var/lib/AccountService/users/${USER} \

| sed 's/Language=//')
if [ "$i" != "" ]; then
export LANG=$i
fi
Japanese, Korean, Chinese, or other languages with a non-Latin character set may not
display properly on local text consoles.
Individual commands can be made to use another language by setting the LANG variable on the
command line:
[user@host ~]$ LANG=fr_FR.utf8 date
JB348-RHJBEAP7-en-6-20170411 xv
Introduction
jeu. avril 24 17:55:01 CDT 2014
Subsequent commands will revert to using the system's default language for output. The locale
command can be used to check the current value of LANG and other related environment
variables.
Input method settings

GNOME 3 in Red Hat Enterprise Linux 7 automatically uses the IBus input method selection
system, which makes it easy to change keyboard layouts and input methods quickly.
The Region & Language application can also be used to enable alternative input methods. In the
Region & Language application's window, the Input Sources box shows what input methods are
currently available. By default, English (US) may be the only available method. Highlight English
(US) and click the keyboard icon to see the current keyboard layout.
To add another input method, click the + button at the bottom left of the Input Sources window.
An Add an Input Source window will open. Select your language, and then your preferred input
method or keyboard layout.
Once more than one input method is configured, the user can switch between them quickly by
typing Super+Space (sometimes called Windows+Space). A status indicator will also appear
in the GNOME top bar, which has two functions: It indicates which input method is active, and
acts as a menu that can be used to switch between input methods or select advanced features of
more complex input methods.
Some of the methods are marked with gears, which indicate that those methods have advanced
configuration options and capabilities. For example, the Japanese Japanese (Kana Kanji) input
method allows the user to pre-edit text in Latin and use Down Arrow and Up Arrow keys to
select the correct characters to use.
US English speakers may find also this useful. For example, under English (United States) is the
keyboard layout English (international AltGr dead keys), which treats AltGr (or the right Alt)
on a PC 104/105-key keyboard as a "secondary-shift" modifier key and dead key activation key
for typing additional characters. There are also Dvorak and other alternative layouts available.
Note
Any Unicode character can be entered in the GNOME desktop environment if the user
knows the character's Unicode code point, by typing Ctrl+Shift+U, followed by the
code point. After Ctrl+Shift+U has been typed, an underlined u will be displayed to
indicate that the system is waiting for Unicode code point entry.
For example, the lowercase Greek letter lambda has the code point U+03BB, and can be
entered by typing Ctrl+Shift+U, then 03bb, then Enter.
System-wide default language settings

The system's default language is set to US English, using the UTF-8 encoding of Unicode as its
character set (en_US.utf8), but this can be changed during or after installation.
From the command line, root can change the system-wide locale settings with the localectl
command. If localectl is run with no arguments, it will display the current system-wide locale
settings.
xvi JB348-RHJBEAP7-en-6-20170411
Language packs
To set the system-wide language, run the command localectl set-locale LANG=locale,
where locale is the appropriate $LANG from the "Language Codes Reference" table in this
chapter. The change will take effect for users on their next login, and is stored in /etc/
locale.conf.
[root@host ~]# localectl set-locale LANG=fr_FR.utf8
In GNOME, an administrative user can change this setting from Region & Language and clicking
the Login Screen button at the upper-right corner of the window. Changing the Language of
the login screen will also adjust the system-wide default language setting stored in the /etc/
locale.conf configuration file.
Important
Local text consoles such as tty2 are more limited in the fonts that they can display
than gnome-terminal and ssh sessions. For example, Japanese, Korean, and Chinese
characters may not display as expected on a local text console. For this reason, it may
make sense to use English or another language with a Latin character set for the
system's text console.
Likewise, local text consoles are more limited in the input methods they support, and
this is managed separately from the graphical desktop environment. The available
global input settings can be configured through localectl for both local text virtual
consoles and the X11 graphical environment. See the localectl(1), kbd(4), and
vconsole.conf(5) man pages for more information.
Language packs
When using non-English languages, you may want to install additional "language packs" to
provide additional translations, dictionaries, and so forth. To view the list of available langpacks,
run yum langavailable. To view the list of langpacks currently installed on the system,
run yum langlist. To add an additional langpack to the system, run yum langinstall
code, where code is the code in square brackets after the language name in the output of yum
langavailable.
References
locale(7), localectl(1), kbd(4), locale.conf(5), vconsole.conf(5),
unicode(7), utf-8(7), and yum-langpacks(8) man pages
Conversions between the names of the graphical desktop environment's X11 layouts and
their names in localectl can be found in the file /usr/share/X11/xkb/rules/
base.lst.
JB348-RHJBEAP7-en-6-20170411 xvii
Introduction
Language Codes Reference

Language Codes
Language $LANG value
English (US) en_US.utf8
Assamese as_IN.utf8
Bengali bn_IN.utf8
Chinese (Simplified) zh_CN.utf8
Chinese (Traditional) zh_TW.utf8
French fr_FR.utf8
German de_DE.utf8
Gujarati gu_IN.utf8
Hindi hi_IN.utf8
Italian it_IT.utf8
Japanese ja_JP.utf8
Kannada kn_IN.utf8
Korean ko_KR.utf8
Malayalam ml_IN.utf8
Marathi mr_IN.utf8
Odia or_IN.utf8
Portuguese (Brazilian) pt_BR.utf8
Punjabi pa_IN.utf8
Russian ru_RU.utf8
Spanish es_ES.utf8
Tamil ta_IN.utf8
Telugu te_IN.utf8
xviii JB348-RHJBEAP7-en-6-20170411
TRAINING
CHAPTER 1
WHAT'S NEW IN JBOSS EAP 7?
Overview
Goal Describe the new features in JBoss EAP 7.
Objectives • Describe the new specifications in Java EE 7.
• Identify new features in the management console in JBoss

EAP 7.
• Describe and explore the new features in JBoss EAP 7.

Sections • Identifying the New Specifications in Java EE 7 (and Quiz)
• Configuring EAP with the New Management Console (and

Guided Exercise)
• Identify New Features in JBoss EAP 7 (and Quiz)

Lab • What's New in JBoss EAP 7?
JB348-RHJBEAP7-en-6-20170411 1
Chapter 1. What's New in JBoss EAP 7?
Identifying the New Specifications in Java EE 7
Objectives
After completing this section, students will be able to describe the new specifications in Java EE
7.
Java EE 7 specification
EAP 7 is compliant with the Java EE 7 specification, implementing both the full and web
profile standards. The following table lists the new and updated Java specification requests
for the JEE 7 version. The final column is the subsystem in EAP 7 that corresponds with the
technology. Each subsystem can be configured to the user's needs either with the EAP CLI or in
the EAP management console. In some instances, a subsystem is compromised of may different
technologies. For example, the EAP 7 replacement for the web subsystem, undertow, consists of
WebSocket, Servlet, JSP, and EL technologies.
While JEE 6 focused heavily on improving the ability to make lightweight web applications, JEE
7 provides more capabilities for creating scalable, HTML 5 dynamic applications. JEE7 features
improvements for RESTful services as well as standard JSON support so that creating APIs
and data processing are simpler than in previous versions. The updated version of JSF, the
technology for building server-side user interfaces, offers a more friendly HTML5 experience by
allowing developers to write standard HTML and pass in JSF attributes that render as pure HTML
when inspected in applications.
A new feature available in Java EE 7 and EAP 7 is the batching technology that allows enterprise
users to run batch processing tasks such as payroll processing or any other bulk process that
needs to be regularly scheduled.
In addition to lots of new features, Java EE 7 also simplifies, consolidates, and removes older
technologies. For example, JAX-RPC (JSR-101) are deprecated and replaced with JAX-WS 2.0.
JAX-RPC, as well as Application Deployment (JSR-88), EJB 2.x, and others, are deprecated in
Java EE 7 and scheduled to be removed in Java EE 8.
Technology JSR Description Subsystem

Batch 1.0 JSR 352 Provides batch processing. batch-jberet
JSON-P 1.0 JSR 353 The Java API for JSON processing. jaxrs
Concurrency JSR 236 Provides a simple, standardized API EE
Utilities for using concurrency from application
components without compromising
container integrity.
WebSocket JSR 356 Defines a Java API for the WebSocket undertow
1.1 protocol.
JMS 2.0 JSR 343 The Java Message Service API is messaging-
responsible for accessing enterprise activemq
messaging systems from Java programs.
JPA 2.1 JSR 338 The Java Persistence API is responsible jpa
for the persistence management.
2 JB348-RHJBEAP7-en-6-20170411
Java EE 7 specification
Technology JSR Description Subsystem

JCA 1.7 JSR 322 Defines a standard architecture for jca
connecting to Enterprise Information
Systems.
JAX-RS 2.0 JSR 339 API for RESTful web services in the Java jaxrs
Platform.
JAX-WS 2.2 JSR 224 The JAX-WS 2.0 specification is the next webservices
generation web services API replacing
JAX-RPC 1.0.
Servlet 3.1 JSR 340 Servlets receive and respond to requests undertow
from web clients.
JSF 2.2 JSR 344 Technology for building server-side user jsf
interfaces.
JSP 2.3 JSR 245 Enables to create dynamic web content. undertow
EL 3.0 JSR 341 Technology responsible for evaluation of undertow
expressions in web pages.
CDI 1.2 JSR 330 Contexts and Dependency Injection for weld
Java EE.
JTA 1.2 JSR 907 Specifies high-level interfaces between transactions
a transaction manager and the parties
involved in a distributed transaction
system.
Common JSR 250 Annotations for common semantic annotations
Annotations concepts in the Java SE and Java EE
1.1 platforms.
EJB 3.2 JSR 345 Allows the development of component- ejb3
based applications.
Bean JSR 349 Standardizes constraint definition, bean-validation
Validation 1.1 declaration and validation for the Java
platform.
JB348-RHJBEAP7-en-6-20170411 3
Quiz: What's New in JBoss EAP 7
Choose the correct answer to the following questions:
1. Which two JSRs are handled by the undertow subsystem? (Choose two.)
a. JSR 356 - WebSocket 1.1.

b. JSR 353 - JSON-P 1.0.
c. JSR 340 - Java Servlet 3.1.
d. JSR 224 - JAX-WS 2.2.
2. Which subsystem is responsible for managing a technology for building server side user
interfaces? (Choose one.)
a. webservices
b. jsf
c. ejb3
d. batch
e. jaxrs
3. Which technology replaced JAX-RPC in JEE 7? (Choose one.)
a. JAX-RS
b. JCA
c. JSP
d. JAX-WS
4 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
1. Which two JSRs are handled by the undertow subsystem? (Choose two.)
a. JSR 356 - WebSocket 1.1.

b. JSR 353 - JSON-P 1.0.
c. JSR 340 - Java Servlet 3.1.
d. JSR 224 - JAX-WS 2.2.
2. Which subsystem is responsible for managing a technology for building server side user
interfaces? (Choose one.)
a. webservices
b. jsf
c. ejb3
d. batch
e. jaxrs
3. Which technology replaced JAX-RPC in JEE 7? (Choose one.)
a. JAX-RS
b. JCA
c. JSP
d. JAX-WS
JB348-RHJBEAP7-en-6-20170411 5
Configuring EAP with the New Management

Console
Objectives
After completing this section, students will be able to identify new features in the management
console in JBoss EAP 7.
Management console features

JBoss EAP 7 features a redesigned management console that simplifies the administration tasks
for the application server. The management console supports the following new features in EAP
7:
• A new home page for quick access for common tasks.
• Support for multiple languages, including English, Brazilian Portuguese, and German.
• Easier navigation, and enhanced support for large-scale domain configurations.
• Log visualization in the web console.
• Management model to visualize and customize the CLI commands using the a web console.
Redesigned home page
Figure 1.1:
The EAP 7 management console home page provides quick access to administration tools.
The redesigned home page provides administrators with quick access to common administration
tasks, such as managing deployments, configuring the server profiles, and monitoring the server
status.
6 JB348-RHJBEAP7-en-6-20170411
Enhanced navigation
Enhanced navigation
Figure 1.2:
The redesigned navigation of the management console streamlines administration tasks.
The UI of the management console has been redesigned for a more intuitive and consistent
experience. In addition, the column views allow users to see more of the available subsystems
and options on the screen than previous versions.
Log visualization in the management console
Figure 1.3:
The server log files are now viewable from within the management console.
Another useful feature is the ability to view different log files from within the management
console. Administrators can download and view log files as well as filter and sort archived log
files.
JB348-RHJBEAP7-en-6-20170411 7
Guided Exercise: Configuring EAP with the

New Management Console
In this exercise, you will use the redesigned EAP 7 management console to deploy a simple
application and adjust the console logger.
Resources
Files: /home/student/JB348/labs/explore-console, /home/
student/JB348/apps/version.war
Application URL: http://localhost:9990, http://localhost:8080/
version
Outcomes
You will be able to manage a standalone instance of EAP using the redesigned management
console.
Before you begin

Use the following command in the workstation VM to verify that an instance of EAP is
installed in the /opt/ directory and to download the server configuration files for this exercise:
[student@workstation ~]$ lab explore-console setup
1. Start a Standalone Instance of EAP

Run the following command in a terminal window on the workstation to start an EAP
instance using the /home/student/JB348/labs/explore-console folder as the base
directory:
[student@workstation ~]$ cd /opt/jboss-eap-7.0/bin

[student@workstation bin]$ ./standalone.sh \
-Djboss.server.base.dir=/home/student/JB348/labs/explore-console/
2. Navigate to the Management Console

Once the server has started, open a web browser and navigate to the management console
at http://localhost:9990. Use the following preconfigured administrator credentials to
log in:
• User Name: jbossadm
• Password: JBoss@RedHat123
3. Deploy the version.war Application

The redesigned JBoss EAP 7 management console has an updated home page with links
to frequently used actions, such as Deployments for deploying applications, Runtime for
viewing the server status, logs and JVM usage, and Configuration for adjusting available
subsystems.
Use the management console to deploy the /home/student/JB348/apps/version.war

application.
8 JB348-RHJBEAP7-en-6-20170411
3.1. Click Deployments in either the top menu bar, or from the management console home
page.
3.2. Next to the Deployment label, click Add.
3.3. Select Upload a new deployment and click Next.
3.4. Click Browse and select the application /home/student/JB348/apps/

version.war. Click Next.
3.5. Leave the default values on the next screen and then click Finish.
3.6. See the deployed version.war application by navigating in a new browser tab to
http://localhost:8080/version.
4. Enable Debug Logging

Return to the management console and increase the console logger from INFO to DEBUG.
4.1. Back in the EAP management console, click Configuration either from the top menu or
from the home screen.
4.2. In the first column, click Subsystems. In the second column, click Logging and then click
View.
4.3. Click Handler at the top of the page to navigate to the Console Handler configuration.
4.4. Under Attributes, click Edit. Update the Level to DEBUG.
4.5. Click Save.
4.6. Click Back in order to return to the main Configuration page.
5. Restart the Server

Use the management console to restart the standalone server to see the effects of the
increased logging level.
5.1. Click Runtime from the top menu in the management console.
5.2. Select Standalone Server in the first column. Click Reload. Click Confirm to reload the
server. A green pop-up notification will confirm that the reload was successful.
5.3. Return to the terminal where the standalone instance of EAP was started to view the
console log. Look for statements like the following to see that the debug statements
appear in the console:
14:34:37,376 DEBUG [org.jboss.as.config] (MSC service thread 1-1) Configured

system properties
5.4. Click Standalone Server after the server finishes reloading. In the Monitor column,
select Log Files and then click View.
5.5. Select the server.log file and click View to observe the server log in the management
console.
JB348-RHJBEAP7-en-6-20170411 9
6. Clean Up and Grading

6.1. Run the following command from the workstation to grade the exercise:
[student@workstation ~]$ lab explore-console grade
6.2. Press Ctrl+C in the terminal window where you started the standalone instance of EAP.
This concludes the guided exercise.
10 JB348-RHJBEAP7-en-6-20170411
Identifying New Features in JBoss EAP 7
Identifying New Features in JBoss EAP 7
Objectives
After completing this section, students will be able to describe and explore the new features in
JBoss EAP 7.
New features of JBoss EAP 7

EAP 7 introduces some useful new features. Principal among the new features are the following:
• CLI Offline Mode: Users can embed an EAP server instance inside the CLI process and work
offline. For example, while in the EAP CLI, users can specify the configuration file to modify
even when the server is not running:
[disconnected /] embed-server --server-config=standalone-full.xml
After running the embed-server command, any subsequent commands configure the
embedded server.
• Graceful shutdown: Use graceful shutdown so that the EAP server waits for all requests to be
handled before stopping.
• Configuration change notifications: Notifications are a useful mechanism to observe

management changes on EAP servers. An administrator is informed of changes made by other
authorized administrators.
• Port reduction: In EAP 7, almost all protocols are multiplexed over two ports; port 9990 is
used for administration and port 8080 is used for applications.
• Performance enhancements: EAP 7 improved its performance with new features like the
undertow subsystem, optimized cluster, JCA distributed work manager, and the undertow load
balancer.
• Batch processing: Using the new batch subsystem, users can create batch jobs in EAP 7.
• Security enhancements: New resources are available related to security such as single sign-
on using PicketLink and KeyCloak, and the Elytron for container and Java EE security.
• ActiveMQ Artemis: HornetQ has been replaced with ActiveMQ Artemis as EAP 7's JMS
broker. ActiveMQ Artemis provides many new messaging features and it retains protocol
compatibility with HornetQ.
Deprecated specifications and features

In EAP 7, some features have been deprecated and may be removed in the future. This means
that no enhancements will be made to these features.
All PicketLink modules, including Federation, were deprecated in JBoss EAP 7. The Resteasy
Jettison Provider was also deprecated.
The following features are now unsupported:
• JAX-RPC: JAX-WS offers a more accurate and complete solution.
JB348-RHJBEAP7-en-6-20170411 11
• Java EE application deployment: JSR 88 had limited adoption.
• JBoss Web Services:
◦ Bean Validation 1.1 interceptors and features
◦ JASPI authentication
• Messaging:
◦ AMQP, Stomp, REST, MQTT, and OpenWire protocol
◦ Netty over HTTP and Netty Servlet transport
◦ OIO (Old Java IO) connectors and acceptors type
◦ Vert.X, AeroGear, Spring, and Jolokia integration
◦ Dynamic queue creation
◦ Chain cluster
◦ Using ActiveMQ Artemis Management using JMX
◦ Use database as shared JDBC store
◦ Scaling down in cluster
◦ Colocated HA topology configured with http-connector/http-acceptor or replication-

colocated/shared-store-colocated
• Management console:
◦ All flush operations for connection pools
◦ Red Hat Access integration
• Resteasy 3:
◦ jose-jwt
◦ resteasy-crypto
◦ resteasy-yaml-provider
• Command Line Interface (CLI):
◦ CLI preferences in .jbossclirc file
◦ Simplify working with complex attributes
◦ CLI tab-completion for attribute name path syntax
◦ Connection controller alias in jboss-cli.xml
◦ RBAC-based tab completion for the CLI commands
• Clustering:
12 JB348-RHJBEAP7-en-6-20170411
Deprecated specifications and features
◦ Cross-site replication
◦ Declarative channels, channel forks, fork protocol stacks, and custom JGroups protocols in
the jgroups subsystem
◦ Public API for JGroups channel creation
◦ Runtime management metrics for JGroups channels
◦ Ability to configure thread pools per protocol stack in the jgroups subsystem
◦ Ability to configure thread pools per cache container in the infinispan subsystem
• Transactions:
◦ Compensable transactions
◦ REST transactions
• Add user: Enable or disable users using add-user utility
• Hibernate: Use generics in Hibernate native API
• PicketLink:
◦ PicketLink IDM
◦ PicketLink IDM subsystem
◦ STS Client Pooling feature of PicketLink Federation
◦ PicketLink JEE (CDI Security)
• JBoss Web
• Natives:
◦ Support was dropped for mod_cluster and mod_jk connectors used with Apache HTTP
server from RHEL RPM channels
◦ Support was dropped for mod_cluster and mod_jk connectors used with Apache HTTP
server from the HP-UX Web Server Suites
◦ OpenSSL
◦ tcnatives
• Undertow: WebDAV functionality is not provided in JBoss EAP 7, but it can be added by
implementing a servlet, which implements the WebDAV functionality.
• ORB
JB348-RHJBEAP7-en-6-20170411 13
Quiz: What's New in JBoss EAP 7
1. Which four new features are available in EAP 7? (Choose four.)
a. Offline mode in CLI

b. Domain mode
c. Port Reduction
d. JAX-RS
e. Graceful shutdown
f. Undertow load balancer
2. Which two of the following features were deprecated in EAP 7? (Choose two.)
a. Modcluster
b. Remote EJB calls
c. All PicketLink modules
d. Bean validation 2.0
e. The Resteasy Jettison Provider
3. Which command enables offline CLI mode in EAP 7? (Choose one.)
a. add-server
b. new-server
c. embed-server
d. enable-server
e. init-server
4. EAP 7 now has almost all protocols multiplexed over which two ports? (Choose two.)
a. 8080
b. 80
c. 9990
d. 8443
e. 19990
14 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
1. Which four new features are available in EAP 7? (Choose four.)
a. Offline mode in CLI

b. Domain mode
c. Port Reduction
d. JAX-RS
e. Graceful shutdown
f. Undertow load balancer
2. Which two of the following features were deprecated in EAP 7? (Choose two.)
a. Modcluster
b. Remote EJB calls
c. All PicketLink modules
d. Bean validation 2.0
e. The Resteasy Jettison Provider
3. Which command enables offline CLI mode in EAP 7? (Choose one.)
a. add-server
b. new-server
c. embed-server
d. enable-server
e. init-server
4. EAP 7 now has almost all protocols multiplexed over which two ports? (Choose two.)
a. 8080
b. 80
c. 9990
d. 8443
e. 19990
JB348-RHJBEAP7-en-6-20170411 15
Lab: What's New in JBoss EAP 7?
In this lab, you will use the JBoss CLI in offline mode and the management console to manage a
standalone instance of JBoss EAP.
Resources
Files: /home/student/JB348/apps/welcome.war, /opt/
jboss-eap-7.0/standalone/configuration/
standalone-lab.xml
welcome
Outcomes
You will be able to manage an EAP instance in offline mode with the JBoss CLI and navigate the
EAP 7 management console to deploy an application and create a datasource.
Before you begin

Use the following command on the workstation to verify that an instance of EAP is installed
in the /opt/ directory and to download the server configuration file standalone-lab.xml for
this exercise:
[student@workstation ~]$ lab whats-new-lab setup
A port conflict in your standalone instance of EAP is causing the server to fail to start. Use CLI in
offline mode to resolve the issue.
Note
It is recommended to use a separate base directory for configuration files, but an
outstanding issue in JBoss EAP 7.0 prevents specifying a separate base directory when
running CLI in offline mode. The issue will be resolved in a future release, but this
exercise utilizes the default base directory.
1. Start the EAP CLI

Start the EAP CLI as the jboss system user from the EAP installed at /opt/jboss-
eap-7.0.
2. Embed a Server for Offline Configuration

Using the EAP CLI, embed the server configuration file located at /opt/jboss-eap-7.0/
standalone/configuration/standalone-lab.xml by using the --server-config
option.
3. Change the Port for the Management Console

Using the CLI, set the management console to run on port 19990 by modifying the port
attribute in the management-http socket binding. Then, exit the CLI.

Verify that the management console is accessible on port 19990 by starting an instance
of EAP from the /opt/jboss-eap-7.0 folder as the jboss user with /opt/jboss-
16 JB348-RHJBEAP7-en-6-20170411
eap-7.0/standalone/configuration/standalone-lab.xml as the server
configuration.
Access the management console in a web browser by navigating to http://

localhost:19990. Use the following credentials to log in:
• User name: jbossadm
5. Create a Datasource in the Management Console

Using the management console, add a new Non-XA, H2 Datasource for development. Use the
default connection values for the datasource except for the following values:
• Name: DevDS
• JNDI Name: java:jboss/datasources/DevDS
Test the connection to verify that EAP can connect to the datasource.
6. Deploy the Welcome Application in the Management Console

Use the management console to deploy the application /home/student/JB348/apps/
welcome.war.
Verify that the application was deployed correctly by visiting http://localhost:8080/

welcome.

[student@workstation ~]$ lab whats-new-lab grade
This concludes the lab.
JB348-RHJBEAP7-en-6-20170411 17
Solution
In this lab, you will use the JBoss CLI in offline mode and the management console to manage a
standalone instance of JBoss EAP.
Resources
Files: /home/student/JB348/apps/welcome.war, /opt/
jboss-eap-7.0/standalone/configuration/
standalone-lab.xml
welcome
Outcomes
You will be able to manage an EAP instance in offline mode with the JBoss CLI and navigate the
EAP 7 management console to deploy an application and create a datasource.
Before you begin

Use the following command on the workstation to verify that an instance of EAP is installed
in the /opt/ directory and to download the server configuration file standalone-lab.xml for
this exercise:
[student@workstation ~]$ lab whats-new-lab setup
A port conflict in your standalone instance of EAP is causing the server to fail to start. Use CLI in
offline mode to resolve the issue.
Note
It is recommended to use a separate base directory for configuration files, but an
outstanding issue in JBoss EAP 7.0 prevents specifying a separate base directory when
running CLI in offline mode. The issue will be resolved in a future release, but this
exercise utilizes the default base directory.
1. Start the EAP CLI

Start the EAP CLI as the jboss system user from the EAP installed at /opt/jboss-
eap-7.0.

[student@workstation bin]$ sudo -u jboss ./jboss-cli.sh
2. Embed a Server for Offline Configuration

Using the EAP CLI, embed the server configuration file located at /opt/jboss-eap-7.0/
standalone/configuration/standalone-lab.xml by using the --server-config
option.
[disconnected /] embed-server --server-config=standalone-lab.xml
18 JB348-RHJBEAP7-en-6-20170411
Solution
3. Change the Port for the Management Console

Using the CLI, set the management console to run on port 19990 by modifying the port
attribute in the management-http socket binding. Then, exit the CLI.
[standalone@embedded /] /socket-binding-group=standard-sockets/\
socket-binding=management-http:write-attribute(name=port,value=19990)
{"outcome" => "success"}

[standalone@embedded /] exit

Verify that the management console is accessible on port 19990 by starting an instance
of EAP from the /opt/jboss-eap-7.0 folder as the jboss user with /opt/jboss-
eap-7.0/standalone/configuration/standalone-lab.xml as the server
configuration.
[student@workstation bin]$ sudo -u jboss ./standalone.sh \

-c standalone-lab.xml
Access the management console in a web browser by navigating to http://

localhost:19990. Use the following credentials to log in:
5. Create a Datasource in the Management Console

Using the management console, add a new Non-XA, H2 Datasource for development. Use the
default connection values for the datasource except for the following values:
• Name: DevDS
• JNDI Name: java:jboss/datasources/DevDS
Test the connection to verify that EAP can connect to the datasource.
• Select Configuration from the top menu in the management console.
• Click Subsystem in the first column and then Datasources in the second column.
• Click Non-XA in the third column and then click Add in the fourth Datasource column.
• Select H2-Datasource in the first Create Datasource screen and then click Next.
• On Step 1/3: Datasource Attributes enter the following values and then click Next:
◦ Name: DevDS
◦ JNDI Name: java:jboss/datasources/DevDS
• Leave the remaining values as default and proceed through the setup until you click Finish
• Click the new DevDS datasource and then click View.
JB348-RHJBEAP7-en-6-20170411 19
• In the Datasources view, click Connection and then click Test Connection. A pop-up
window confirms that the connection is successful.
6. Deploy the Welcome Application in the Management Console

Use the management console to deploy the application /home/student/JB348/apps/
welcome.war.
Verify that the application was deployed correctly by visiting http://localhost:8080/

welcome.
• From the home page of the management console, click Deployments. Then click Add.
• Select Upload a new deployment and then click Next.
• Click Browse and select /home/student/JB348/apps/welcome.war. Click Next.
• Leave the default values and then click Finish.
• In Firefox, navigate to http://localhost:8080/welcome and verify that the Welcome

application was deployed correctly.

[student@workstation ~]$ lab whats-new-lab grade
20 JB348-RHJBEAP7-en-6-20170411
Summary
Summary
In this chapter, you learned:
• JBoss EAP 7 is compliant with the Java EE 7 specification, which includes updates for JMS,
JPA, JAX-WS, JAX-RS, CDI, and more.
• The management console has been redesigned for easier navigation. From the home screen,
administrators can access the deployments, configuration, the runtime information, and
modify the access control.
• The management console provides the ability to view server logs and to gracefully shut down
and restart the server.
• Administrators can use CLI in offline mode to make configuration changes by embedding a
server with the embed-server command.
• The number of ports in use in EAP 7 has been reduced to two: 8080 and 9990.
• HornetQ has been replaced in EAP 7 with ActiveMQ Artemis.
• The management console no longer supports flush operations for connection pools.
• All PicketLink modules were deprecated in JBoss EAP 7.
JB348-RHJBEAP7-en-6-20170411 21
22
TRAINING
CHAPTER 2
MIGRATING TO JBOSS EAP 7
Overview
Goal Explore strategies for migrating from JBoss EAP 6 to JBoss
EAP 7.
Objectives • Identify considerations for migrating JBoss EAP 6
applications to JBoss EAP 7.
• Utilize the Windup tool to generate an EAP 6 to EAP 7

migration report.
• Migrate an EAP 6 server to EAP 7 with JBoss Server

Migration Tool.
Sections • Migrating JBoss EAP 6 Applications to JBoss EAP 7 (and
Quiz)
• Generating a Windup Report (and Guided Exercise)
• Planning a Migration with JBoss Server Migration Tool

(and Guided Exercise)
Lab • Migrating to JBoss EAP 7
JB348-RHJBEAP7-en-6-20170411 23
Chapter 2. Migrating to JBoss EAP 7
Migrating JBoss EAP 6 Applications to JBoss

EAP 7
Objectives
After completing this section, students will be able to:
• Describe strategies for migrating JBoss EAP 6 applications to JBoss EAP 7.
• Describe the new features in EAP 7 as well as the deprecated technologies.
Migrating from EAP 6 to EAP 7

In EAP 7, an effort was made to maintain backward compatibility for applications deployed on
EAP 6. However, if the application or the server utilizes features that are deprecated in EAP 7,
the application and the server must be updated to be compatible with EAP 7.
The following are major features that were available in earlier EAP releases that have been
deprecated in EAP 7:
• EJB 2 Container Managed Persistence (CMP): EJB 2 style Entity Beans (CMP) are no longer
supported. Use JPA for a more flexible and efficient API.
• JAX-RPC: Migrate to JAX-WS or JAX-RS for a more secure and flexible API.
• JSR-88: A specification for a standard application deployment API, which was not widely
adopted. Use the EAP CLI or the EAP management console for application deployment.
• Generic JMS Resource Adapter: The ability to configure a generic JMS resource adapter to
connect to a third party JMS provider is no longer supported in JBoss EAP 7. Check with the
JMS provider to see if they have their own resource adapter that can be used with JBoss EAP.
In addition, EAP 7 has a number of new features and changes that may impact application
deployment. The major changes:
• Undertow: Undertow has replaced JBoss Web as the web server in JBoss EAP 7. This means
that the legacy web subsystem configuration must be migrated to the new EAP 7 undertow
subsystem configuration:
◦ The urn:jboss:domain:web:2.2 subsystem configuration namespace in the server

configuration file has been replaced by the urn:jboss:domain:undertow:3.1
namespace.
◦ The org.jboss.as.web extension module, located in JBOSS_HOME/modules/system/

layers/base/, has been replaced with the org.wildfly.extension.undertow
extension module.
◦ Earlier versions of EAP supported global valves, which are custom classes inserted into
the request processing pipeline to make changes to the request or to perform additional
processing (for example, single sign-on). Valves must be migrated to use undertow handlers
instead. Undertow includes a number of built-in handlers that provide common functionality.
It also provides the ability to create custom handlers, which can be used to replace custom
valve functionality.
24 JB348-RHJBEAP7-en-6-20170411
Tools to assist migration to EAP 7
• JGroups: There are several changes to the jgroups subsystem:
◦ In earlier EAP versions, JGroups used the public interface defined in the <interfaces>
section of the server configuration file. In EAP 7, JGroups uses the new private interface
that is defined in the <interfaces> sections of the server configuration file in the ha and
full-ha profiles.
◦ Group communication support for HA services is provided in the form of JGroups

channels. EAP 7 introduces <channel> elements to the jgroups subsystem in the server
configuration file. You can add, remove, or change the configuration of JGroups channels
using the EAP CLI.
• Messaging: In EAP 7, ActiveMQ Artemis replaces HornetQ as the messaging support provider.
The subsystem configuration has been changed:
◦ The urn:jboss:domain:messaging:3.0 subsystem configuration namespace in the

server configuration file has been replaced by the urn:jboss:domain:messaging-
activemq:1.0 namespace.
◦ The org.jboss.as.messaging extension module, located in JBOSS_HOME/

modules/system/layers/base/, has been replaced with the
org.wildfly.extension.messaging-activemq extension module.
◦ In earlier versions of EAP, JMS destinations were configured in the <jms-destinations>

element under the <hornetq-server> element in the messaging subsystem. In EAP
7, the JMS destination queue is configured in the default <server> element of the
messaging-activemq subsystem.
• Ports Reduction: Earlier versions of EAP used a number of different ports for protocol-specific
communication. By utilizing HTTP upgrade, EAP 7 has moved nearly all of its protocols to be
multiplexed over two HTTP ports: a management port (9990), and an application port (8080).
• EJB Clients: In EAP 7, the default connector has changed from remote to http-remoting
and the default remote connection port has changed from 4447 to 8080. The JNDI provider
URL for the default configuration has changed from remote://server:4447 to http-
remoting://server:8080.
• Picketbox and Picketlink Federation: In EAP 7, the Picketbox and Picketlink Federation APIs
have been deprecated and will be removed in future EAP releases. They have been replaced
by the Elytron project. See http://lists.jboss.org/pipermail/wildfly-dev/2014-
June/002244.html for more details).
Tools to assist migration to EAP 7

Red Hat provides several tools to assist migrating applications deployed on earlier EAP versions
to EAP 7.
The EAP CLI provides the operation migrate to migrate the jacorb, messaging and web
subsystems from EAP 6. Note that the migrate operation does not fully automate the migration
to EAP 7 and a few subsystems that were deprecated in EAP 7 have to be removed manually.
To get started, copy the configuration file from the EAP 6 instance of EAP into the new EAP 7
configuration directory:
$ cp EAP6_DIRECTORY/standalone/configuration/standalone.xml \
JB348-RHJBEAP7-en-6-20170411 25
EAP7_DIRECTORY/standalone/configuration
After copying the configuration, the EAP 7 server and EAP CLI can be started as normal. Before
performing the actual migration, run the describe-migration operation to view the list of
proposed changes that the migration operation will make to the configuration. For example, to
view the changes for the messaging subsystem:
[standalone@localhost:9999 /] /subsystem=messaging:describe-migration
After reviewing which changes are going to be made, execute the actual migration:
[standalone@localhost:9999 /] /subsystem=messaging:migrate
Similarly, migrate the jacorb and web subsystems:
[standalone@localhost:9999 /] /subsystem=jacorb:migrate
[standalone@localhost:9999 /] /subsystem=web:migrate
Note
The migration operation sometimes displays a lot of warning messages. Consult the
EAP 7 migration guide for the detailed list of warning messages and how to fix them.
In addition to the EAP CLI migrate command, users can take advantage of Windup to facilitate
application migration and JBoss Server Migration Tool for EAP server configuration migration.
Both of these tools will be discussed in detail throughout this chapter.
References
Additional information is available in the chapter on EAP migration in the EAP
documentation, which can be found at
https://access.redhat.com/documentation/en-us/index.html
26 JB348-RHJBEAP7-en-6-20170411
Quiz: Migrating Applications to JBoss EAP 7
1. Which of the following can be used for request preprocessing in EAP 7 instead of valves?
(Choose one.)
a. Undertow load balancer.

b. Undertow valves.
c. Undertow handlers.
d. There is no replacement in EAP 7.
2. Which of the following sentences is true for Undertow? (Choose one.)
a. Undertow is an improved version of JBoss Web.

b. Valves must be migrated from previous releases of EAP to handlers.
c. The module of Undertow is located at org.jboss.as.web.
d. No migration is needed from EAP 6 JBoss Web.
3. Which of the following two statements about the JGroups subsystem in EAP 7 are true?
(Choose two.)
a. JGroups uses the private interface defined in the EAP configuration file.
b. JGroups uses the public interface defined in the EAP configuration file.
c. JGroups has been deprecated in EAP 7.
d. JGroups does not support TCP-based clustering. This feature has been deprecated.
e. JGroups supports both UDP and TCP-based clustering.
4. The EAP 7 messaging subsystem is based on which implementation? (Choose one.)
a. HornetQ
b. ActiveMQ Artemis
c. JBoss Messaging
d. JBossMQ
e. None of the above
JB348-RHJBEAP7-en-6-20170411 27
Solution
1. Which of the following can be used for request preprocessing in EAP 7 instead of valves?
(Choose one.)
a. Undertow load balancer.

b. Undertow valves.
c. Undertow handlers.
d. There is no replacement in EAP 7.
2. Which of the following sentences is true for Undertow? (Choose one.)
a. Undertow is an improved version of JBoss Web.

b. Valves must be migrated from previous releases of EAP to handlers.
c. The module of Undertow is located at org.jboss.as.web.
d. No migration is needed from EAP 6 JBoss Web.
3. Which of the following two statements about the JGroups subsystem in EAP 7 are true?
(Choose two.)
a. JGroups uses the private interface defined in the EAP configuration file.
b. JGroups uses the public interface defined in the EAP configuration file.
c. JGroups has been deprecated in EAP 7.
d. JGroups does not support TCP-based clustering. This feature has been deprecated.
e. JGroups supports both UDP and TCP-based clustering.
4. The EAP 7 messaging subsystem is based on which implementation? (Choose one.)
a. HornetQ
b. ActiveMQ Artemis
c. JBoss Messaging
d. JBossMQ
28 JB348-RHJBEAP7-en-6-20170411
Generating a Windup Report
Generating a Windup Report
Objectives
After completing this section, students will be able to utilize the Windup tool to generate an EAP
6 to EAP 7 migration report.
Windup Migration Platform
Windup is an extensible rule-based tool that facilitates the migration of Java applications.
Windup analyzes application artifacts as either source directories or as application archives and
produces an HTML report that highlights the migration changes triggered by the Windup rules.
Windup can be used to migrate Java applications from previous versions of JBoss EAP to EAP
7, as well as from other containers. By providing an overview of the technologies used by an
application, users have an easier time estimating, documenting, and migrating applications.
Features of Windup
Windup provides the following features:
• Complex rule interaction, allowing rules to pass findings to other rules.
• XML-based rules are simple to write and easy to implement.
• Extensible by developers, users, and third party software.
• Windup reports are targeted for specific audiences, with one report catering to project
managers and another report for developers.
• Reports for an estimated level of effort, based on the skills required for the migration work.
Running Windup
Executing Windup on either a source code directory or application archive is simple and can be
executed in a single command. Use the following syntax to create a Windup report:
$ WINDUP_HOME/bin/windup.sh --input /path/to/sample.war \

--output /path/to/output --source eap:5 --target eap:7
• --input: The application to be evaluated.
• --output: the output directory for the generated reports.
• --source: the source technology for the application migration.
• --target: The target technology for the application migration.
• --packages: The packages to be evaluated.
JB348-RHJBEAP7-en-6-20170411 29
Note
To run Windup against a source directory, use the option --sourceMode and enter the
path for the directory as the input.
Reviewing the report

After executing the Windup command, an HTML report is generated in the specified output
directory. Use a browser to open the index.html in the output directory to see the full Windup
report. The initial page of the Windup report is the Application List landing page. This displays
each application that was processed as well as the number of incidents and story points required
in order to migrate.
Clicking on an application takes users to the Application Report. From there, users can access
any of the following useful reports as well as several others:
• Migration Issues: Provides a concise summary of all issues that require attention.
• Application Details: Provides a detailed overview of all resources found within the application
that may need attention during migration.
• Unparsable: Shows all files that Windup could not parse.
• Dependencies: Displays all Java-packaged dependencies found within the application.
• Remote Services: Displays all remote services references found in the application.
Using the Migration Issues report provides quick access to items that need attention for
migration by directly linking to source code files that may need changes.
30 JB348-RHJBEAP7-en-6-20170411
Reviewing the report
Clicking on an issue opens a hint from the relevant rule that identifies the issue and provides
guidance for resolving the issue. To the right of the issue, Windup estimates the number of story
points to resolve the issue indicating the level of effort required for a fix.
References
Windup
http://windup.jboss.org/
JB348-RHJBEAP7-en-6-20170411 31
Guided Exercise: Analyzing a Migration with

Windup
In this exercise, you will use Windup to analyze effort required for migrating a JBoss EAP 6
application to JBoss EAP 7.
Resources
Files: /home/student/JB348/apps/RESTfulExample.war,
/home/student/JB348/labs/windup-
distribution-2.7.0.Final/
Application URL: file:///home/student/JB348/labs/windup-output/
index.html
Outcomes
You will be able to analyze an application level of effort for migration from JBoss EAP 6 to JBoss
EAP 7.
Before you begin

Use the following command in the workstation VM to download the required files for this
exercise:
[student@workstation ~]$ lab windup-migration setup
1. The RESTful 2 client application /home/student/JB348/apps/RESTfulExample.war

originally ran on JBoss EAP 6. The owners of the client are considering upgrading from EAP
6 to EAP 7 and want to understand the level of effort required to run a JAX-RS client built
on RESTful 2 on EAP 7.
Navigate to the Windup EAP 7 rules directory, /home/student/JB348/labs/windup-

distribution-2.7.0.Final/rules/migration-core/eap7/eap6 for EAP 6 to EAP
7 migrations.
This directory contains all of the rules used to facilitate application migration. Open the file
resteasy.windup.xml in a text editor.
2. Within the RESTeasy rule file, notice the following rule that begins around line 38 of the
resteasy.windup.xml:
<rule id="resteasy-eap6-000002">
<when>
<javaclass references="org.jboss.resteasy.client.ClientRequest" />
</when>
<perform>
<hint title="Deprecated class ClientRequest in RESTEasy 3" effort="1"
severity="optional">
<message><![CDATA[
Replace class `org.jboss.resteasy.client.ClientRequest` with
`org.jboss.resteasy.client.jaxrs.ResteasyClient`.
...OUTPUT OMITTED...
</hint>
</perform>
32 JB348-RHJBEAP7-en-6-20170411
</rule>
The rule targets any uses in the application of the Java class
org.jboss.resteasy.client.ClientRequest. If there is a match, Windup
provides the data in the <hint> tag to identify the level of effort, severity, and a
recommended fix. In this case, the recommendation is to replace the Java class with
org.jboss.resteasy.client.jaxrs.ResteasyClient.
3. Open a new terminal window and navigate to /home/student/JB348/labs/windup-

distribution-2.7.0.Final/bin/. Then run the following command to execute Windup
on the RESTeasy client application, setting the source as eap6, the target as eap7, and the
output directory to /home/student/JB348/labs/windup-output:
[student@workstation ~]$ cd /home/student/JB348/labs/\

windup-distribution-2.7.0.Final/bin/
[student@workstation bin]$ ./windup --input \
/home/student/JB348/apps/RESTfulExample.war \
--output /home/student/JB348/labs/windup-output --source eap:6 --target eap:7
4. After running the command, wait for the Windup report to finish generating. The following
output appears when the report is ready for viewing:
Windup report created: /home/student/JB348/labs/windup-output/index.html

Access it at this URL: file:///home/student/JB348/labs/windup-output/index.html
Open the URL, file:///home/student/JB348/labs/windup-output/index.html,

in the web browser to view the report. The report should similar to the following:
Note
The number of story points you see may differ from the screenshots.
5. Click RESTfulExample.war to see a further break down of the report. Explore the results
page and notice that all of the issues are technically "optional" and originate from the
org.jboss.* package.
6. At the top of the page, click Migration Issues to see the recommended fixes for migrating
from EAP 6 to EAP 7.
JB348-RHJBEAP7-en-6-20170411 33
The story points are concentrated around both "deprecated class" issues. Expand the
information by clicking the first Deprecated class ClientRequest in RESTEASY3.
7. Expand the issue to view the rule explanation, hint, and a link to the incident in the code.
Click com.redhat.rest.client.RESTEasyClientGet to be taken to the Source Report page.
Explore the page. The report identifies the areas where the deprecated class is being used,
and provides hints for how to resolve the issue.
8. Continue exploring the remainder of the report to see other metrics that are relevant to
developing a migration plan. When you are finished, run the following command to verify
that the Windup report was generated correctly.
[student@workstation ~]$ lab windup-migration grade
34 JB348-RHJBEAP7-en-6-20170411
Planning a Migration with JBoss Server Migration Tool
Planning a Migration with JBoss Server

Migration Tool
Objectives
After completing this section, students will be able to migrate an EAP 6 server to EAP 7 with
JBoss Server Migration tool.
Server Migration
Migrating a server configuration can quickly become a complex task that requires administrators
to have a deep understanding of all the technological changes between versions of JBoss EAP.
Traditionally, each subsystem needed to be individually migrated to ensure compliance with new
standards and to avoid deprecated technologies. For example, migrating the HornetQ subsystem
on EAP 6 to the ActiveMQ Artemis messaging subsystem would jave required an administrator to
study both subsystems and ensure that the values were properly ported over. This process would
need to be repeated many times ensure a proper migration.
To cut down on this arduous task, the JBoss Server Migration Tool automates the server
configuration migration. Using a simple script and a fresh installation of EAP 7, users can specify
the original EAP 6 server configuration and the migration tool will automatically translate the
subsystems to their newer counterpart.
Running the Server Migration tool

Start the Server Migration tool using the following syntax:
$ ./server-migration.sh --source ../jboss-eap-6.4

--target ../jboss-eap-7.0
In this instance, the source refers to the directory of the EAP 6 installation that users wish to
upgrade to EAP 7. The target refers to the directory of the server the user wishes to migrate to.
In many cases, the target will be a fresh installation of EAP 7.
After executing the script, the Server Migration tool prompts the user for a specific server
configuration file to use during migration standalone.xml, standalone-full.xml,
standalone-ha.xml, and standalone-full-ha.xml, or all of the files. The tool performs
the following migrations:
• Subsystems Migration
This task migrates the subsystem configuration in the source Standalone server configuration
file by removing unsupported subsystems, migrating the configuration of deprecated
subsystems into their updated counterpart, updates previous configurations to the EAP 7
defaults, and adds the new EAP 7 subsystems.
• Security Realms Migration
The EAP 7 Security Realms configuration is fully compatible with the EAP 6 Security Realms
configuration and therefore requires no change. Property files referenced by the configuration
are copied to the target path.
• Management Interfaces Migration
JB348-RHJBEAP7-en-6-20170411 35
EAP 7 requires the HTTP Management Interface to support HTTP Upgrade for the
Management Console and the EAP CLI. The Server Migration tool enables this feature.
• Socket Bindings Migration
This migration ensures that the management-https socket binding is set to 9993 since this
port is used by the EAP 7 CLI.
After migration, the original configuration files are kept as a backup to prevent accidentally
corrupting the configuration.
References
Additional information may be available in the JBoss Server Migration Tool User Guide,
which can be found at
https://docs.jboss.org/
36 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Migration with JBoss Server Migration Tool
Guided Exercise: Migration with JBoss Server

Migration Tool
In this exercise, you will use the JBoss server migration tool to migrate an EAP 6.4 server to EAP
7.
Resources
Files: /home/student/JB348/labs/eap7/, /home/student/
JB348/labs/jboss-eap-6.4/jboss-eap-6.4, /home/
student/JB348/apps/messaging-client.war, /home/
student/JB348/labs/jboss-server-migration
Application URL: http://localhost:8080/messaging-client
Outcomes
You will be able to migrate an existing standalone instance of EAP 6.4 to EAP 7.
Before you begin

Use the following command in the workstation VM to download the JBoss Server Migration
tool and an EAP 6.4 instance required for this exercise:
[student@workstation ~]$ lab migration-tool setup
1. A fresh install of EAP 6.4 is available at /home/student/JB348/labs/jboss-eap-6.4/

jboss-eap-6.4. In this guided exercise, you will migrate the standalone-full.xml
server configuration file to EAP 7.
Navigate to the EAP 6.4 directory and open the /home/student/JB348/labs/jboss-

eap-6.4/jboss-eap-6.4/standalone/configuration/standalone-full.xml
configuration file. Within the file, the messaging subsystem is at line 272, but EAP 7 no
longer supports it. This, and any other deprecated subsystem, must be migrated. The JBoss
Server Migration tool will convert the already populated values into the EAP 7 configuration
file.
There is an additional ExampleQueue in the subsystem, as well as the cluster password

RedHat@JBoss123. These values will be transcribed into the new EAP 7 subsystem after
running the JBoss Server Migration tool.
...
<subsystem xmlns="urn:jbossomain:messaging:1.4">
<hornetq-server>
<persistence-enabled>true</persistence-enabled>
<cluster-password>RedHat@JBoss123</cluster-password>
<journal-type>NIO</journal-type>
<journal-min-files>2</journal-min-files>
...
...
<jms-destinations>
<jms-queue name="ExpiryQueue">
<entry name="java:/jms/queue/ExpiryQueue"/>
JB348-RHJBEAP7-en-6-20170411 37
</jms-queue>
<jms-queue name="DLQ">
<entry name="java:/jms/queue/DLQ"/>
</jms-queue>
<jms-queue name="ExampleQueue">
<entry name="java:/jms/queue/ExampleQueue"/>
<durable>true</durable>
</jms-queue>
</jms-destinations>
</hornetq-server>
...
2. In a new terminal window, navigate to the JBoss Server Migration tool located at /home/
student/JB348/labs/jboss-server-migration.
[student@workstation ~]$ cd /home/student/JB348/labs/jboss-server-migration
3. Within the jboss-server-migration directory is the server-migration.sh script.

The script requires two options, source, for the server directory to migrate from, and
target for the path to the server to migrate to, in this case a fresh installation of JBoss
EAP 7.
Use the /home/student/JB348/labs/jboss-eap-6.4/jboss-eap-6.4/ directory

as the source and /home/student/JB348/labs/eap7/ directory as the target. In
addition, use the interactive option to only migrate the standalone-full.xml.
[student@workstation jboss-server-migration]$ ./server-migration.sh --source \

/home/student/JB348/labs/jboss-eap-6.4/ --target \
/home/student/JB348/labs/eap7/ --interactive true
4. After running the command, you are presented with the following prompt. Respond with no,
as the only file that needs to be migrated is the standalone-full.xml:
Migrate all configurations?

yes/no? no
5. Continue to enter no until prompted for migrating the standalone-full.xml, at which

point enter yes.
Migrate configuration /home/student/JB348/labs/jboss-eap-6.4/standalone/

configuration/standalone.xml ?
yes/no? no

configuration/standalone-ha.xml ?
yes/no? no

configuration/standalone-full.xml ?
yes/no? yes
6. The migration process runs, ending with a final prompt to migrate the standalone-full-
ha.xml. Enter no in the terminal and the migration is complete.
38 JB348-RHJBEAP7-en-6-20170411
7. Open the /home/student/JB348/labs/eap7/standalone/configuration/
standalone-full.xml configuration file to see the results of the server migration. The
Server Migration tool has created a backup version of the standalone-full.xml by
renaming the file to standalone-full.xml.beforeMigration.
Open the standalone-full.xml in a text editor. Find the ActiveMQ subsystem

configuration at line 379 to see the migrated messaging subsystem.
<subsystem xmlns="urn:jbossomain:messaging-activemq:1.0">
<server name="default">
<cluster password="RedHat@JBoss123"/>
<journal type="NIO"/>
<shared-store-master/>
<security-setting name="#">
<role name="guest" delete-non-durable-queue="true" create-non-
durable-queue="true" consume="true" send="true"/>
</security-setting>
<address-setting name="#" message-counter-history-day-
limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-
address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
<http-connector name="http-connector" endpoint="http-acceptor"
socket-binding="http"/>
<remote-connector name="netty" socket-binding="messaging"/>
<remote-connector name="netty-throughput" socket-binding="messaging-
throughput">
<param name="batch-delay" value="50"/>
</remote-connector>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="http"/>
<remote-acceptor name="netty" socket-binding="messaging"/>
<remote-acceptor name="netty-throughput" socket-binding="messaging-
throughput">
<param name="direct-deliver" value="false"/>
</remote-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/
>
<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
<jms-queue name="ExampleQueue" entries="java:/jms/queue/ExampleQueue"/>
<connection-factory name="InVmConnectionFactory" entries="java:/
ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory"
entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="netty"/>
<pooled-connection-factory name="hornetq-ra" transaction="xa"
entries="java:/JmsXA" connectors="in-vm"/>
</server>
</subsystem>
8. Using the terminal window, start a standalone instance of EAP 7 with the migrated
standalone-full.xml configuration file.
[student@workstation jboss-server-migration]$ cd /opt/jboss-eap-7.0/bin

[student@workstation bin]$ ./standalone.sh -c standalone-full.xml \
-Djboss.server.base.dir=/home/student/JB348/labs/eap7/standalone
9. In a new terminal window, start an EAP CLI session and then deploy the messaging-
client.war application:
JB348-RHJBEAP7-en-6-20170411 39

[student@workstation bin]$ ./jboss-cli.sh -c
[standalone@localhost:9990 /] deploy /home/student/JB348/apps/messaging-client.war
10. The messaging-client.war application is configured to use the

InVmConnectionFactory and place messages on the ExampleQueue.
Verify that the application successfully deployed by navigating to http://

localhost:8080/messaging-client and send a few test messages.
Note
None of the messages will be "received" as there is no MDB deployed, however the
application demonstrates that the queue was successfully migrated from HornetQ
to ActiveMQ Artemis.
11. Grading and Clean Up

11.1. Run the following command to verify that the server configuration was correctly
migrated.
[student@workstation ~]$ lab migration-tool grade
11.2. Press Ctrl+C in the terminal window where you started the standalone instance of EAP
7 to stop the server.
40 JB348-RHJBEAP7-en-6-20170411
Lab: Migrating to JBoss EAP 7
Lab: Migrating to JBoss EAP 7
In this lab, you will generate a migration report for an application and migrate a server from EAP
6 to EAP 7.
Resources
Files: /home/student/JB348/apps/jboss-helloworld-
mdb, /home/student/JB348/apps/jboss-helloworld-
mdb-eap7, /home/student/JB348/labs/windup-
Application URL: file:///home/student/JB348/labs/windup-lab-
output/index.html, http://localhost:8080/jboss-
helloworld-mdb-eap7
Outcomes
You will be able to create a Windup report for an application and migrate an instance of EAP
from EAP 6.4 to EAP 7 using JBoss Server Migration Tool.
Before you begin

Use the following command on the workstation to verify that an instance of EAP 6.4 and
EAP 7 are each installed in the /home/student/JB348/labs/ directory, and to download the
jboss-helloworld-mdb application:
[student@workstation ~]$ lab migrating-lab setup
Your organization has tasked you with scoping out the level of effort required to migrate all of
the organization's applications and servers from EAP 6.4 to EAP 7. Create a proof of concept to
present to the organization by migrating one of the organization's applications and the server it
is running on from EAP 6.4 to EAP 7.
1. Create a Windup Report

Run Windup from the /home/student/JB348/labs/windup-
distribution-2.7.0.Final/ directory against the /home/student/JB348/apps/
jboss-helloworld-mdb.war EAP 6 MDB application. Set the output folder to /home/
student/JB348/labs/migrating-lab-output.
2. Analyze the Report

Access the Windup report by navigating to file:///home/student/JB348/labs/
migrating-lab-output/index.html in a web browser. Analyze the report to find the
incidents.
3. Discover the Fix

Compare the hornetq-jms.xml file and the automatically generated XML file from
Windup. Notice the differences between the two files. By updating this file, EAP 7 will be able
to interpret and create the necessary queues for the application.
Click Proprietary JMS Resource Definitions and to see the hint adjacent to the WEB-INF/
hornetq-jms.xml file name. The hint indicates that proprietary JMS XML descriptors are
deprecated in EAP 7, as HornetQ is no longer supported. Click WEB-INF/hornetq-jms.xml
and then click JMS Resource Definition (Windup Generated) to see the automatically
JB348-RHJBEAP7-en-6-20170411 41
generated XML file. This file can replace the currently existing WEB-INF/hornetq-
jms.xml in the application.
4. Migrate the EAP 6.4 Server

Now that the application has been reviewed for migration, use the JBoss Server Migration
Tool to migrate the EAP 6.4 server that runs the application to EAP 7.
Using ONLY the standalone-full-ha.xml as the configuration file for the EAP server
located at /home/student/JB348/labs/jboss-eap-6.4/jboss-eap-6.4/, migrate
the server to the target EAP 7 server located at /home/student/JB348/labs/eap7/.
5. Start EAP 7
Using the terminal window, start a standalone instance of EAP 7 with the migrated
standalone-full-ha.xml configuration file.
6. Monitor the Server Log

Using a new terminal window, use the following command to monitor the /home/student/
JB348/labs/eap7/standalone/log/server.log server log:
[standalone@workstation ~] tail -f /home/student/JB348/labs/eap7/standalone/log/\

server.log
7. Deploy the Migrated Application

To confirm that the server has been correctly migrated, deploy the application jboss-
helloworld-mdb-eap7, which is the same application as before, except that it has been
migrated to EAP 7 using the recommended Windup fix.
Note
There are several ways to migrate the MDB application to work with EAP
7. Another option is to remove the *-jms.xml file and either create the
queues in the EAP configuration or define the queues in the client using
@JMSDestinationDefinition.

localhost:8080/jboss-helloworld-mdb-eap7. Confirm that the messages are
received by looking at the server logs in the terminal window tailing the log file located at /
home/student/JB348/labs/eap7/standalone/log/server.log.
12:03:50,566 INFO [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-1

(ActiveMQ-client-global-threads-1828526300)) Received Message from queue: This is
message 1
message 4
message 5
message 3
42 JB348-RHJBEAP7-en-6-20170411
message 2

[student@workstation ~]$ lab migrating-lab grade
JB348-RHJBEAP7-en-6-20170411 43
Solution
In this lab, you will generate a migration report for an application and migrate a server from EAP
6 to EAP 7.
Resources
Files: /home/student/JB348/apps/jboss-helloworld-
mdb, /home/student/JB348/apps/jboss-helloworld-
mdb-eap7, /home/student/JB348/labs/windup-
Application URL: file:///home/student/JB348/labs/windup-lab-
output/index.html, http://localhost:8080/jboss-
helloworld-mdb-eap7
Outcomes
You will be able to create a Windup report for an application and migrate an instance of EAP
from EAP 6.4 to EAP 7 using JBoss Server Migration Tool.
Before you begin

Use the following command on the workstation to verify that an instance of EAP 6.4 and
EAP 7 are each installed in the /home/student/JB348/labs/ directory, and to download the
jboss-helloworld-mdb application:
[student@workstation ~]$ lab migrating-lab setup
Your organization has tasked you with scoping out the level of effort required to migrate all of
the organization's applications and servers from EAP 6.4 to EAP 7. Create a proof of concept to
present to the organization by migrating one of the organization's applications and the server it
is running on from EAP 6.4 to EAP 7.
1. Create a Windup Report

Run Windup from the /home/student/JB348/labs/windup-
distribution-2.7.0.Final/ directory against the /home/student/JB348/apps/
jboss-helloworld-mdb.war EAP 6 MDB application. Set the output folder to /home/
student/JB348/labs/migrating-lab-output.
[student@workstation ~]$ cd /home/student/JB348/labs/\

windup-distribution-2.7.0.Final/bin/
[student@workstation bin]$ ./windup --input /home/student/\
JB348/apps/jboss-helloworld-mdb.war \
--output /home/student/JB348/labs/migrating-lab-output \
--source eap:6 --target eap:7
2. Analyze the Report

Access the Windup report by navigating to file:///home/student/JB348/labs/
migrating-lab-output/index.html in a web browser. Analyze the report to find the
incidents.
In the report, click Migration Issues from the top menu. The Proprietary JMS Resource
Definitions has one or more story points assigned and the level of effort is "Trivial."
44 JB348-RHJBEAP7-en-6-20170411
Solution
3. Discover the Fix

Compare the hornetq-jms.xml file and the automatically generated XML file from
Windup. Notice the differences between the two files. By updating this file, EAP 7 will be able
to interpret and create the necessary queues for the application.
Click Proprietary JMS Resource Definitions and to see the hint adjacent to the WEB-INF/
hornetq-jms.xml file name. The hint indicates that proprietary JMS XML descriptors are
deprecated in EAP 7, as HornetQ is no longer supported. Click WEB-INF/hornetq-jms.xml
and then click JMS Resource Definition (Windup Generated) to see the automatically
generated XML file. This file can replace the currently existing WEB-INF/hornetq-
jms.xml in the application.
The link JMS migration documentation inside the hint points to the Migration Guide,
explaining which aspects of the XML file are no longer supported in EAP 7. Primarily, the
namespace is different and hornetq-server element must now be server.
4. Migrate the EAP 6.4 Server

Now that the application has been reviewed for migration, use the JBoss Server Migration
Tool to migrate the EAP 6.4 server that runs the application to EAP 7.
Using ONLY the standalone-full-ha.xml as the configuration file for the EAP server
located at /home/student/JB348/labs/jboss-eap-6.4/jboss-eap-6.4/, migrate
the server to the target EAP 7 server located at /home/student/JB348/labs/eap7/.
[student@workstation bin]$ cd /home/student/JB348/\

labs/jboss-server-migration
[student@workstation jboss-server-migration]$ ./server-migration.sh \
--source /home/student/JB348/labs/jboss-eap-6.4/jboss-eap-6.4/ \
--target /home/student/JB348/labs/eap7/ --interactive true
Migrate all configurations?

yes/no? no

configuration/standalone.xml ?
yes/no? no

configuration/standalone-ha.xml ?
yes/no? no

configuration/standalone-full.xml ?
yes/no? no

configuration/standalone-full-ha.xml ?
yes/no? yes
5. Start EAP 7
Using the terminal window, start a standalone instance of EAP 7 with the migrated
standalone-full-ha.xml configuration file.

[student@workstation bin]$ ./standalone.sh -c standalone-full-ha.xml \
JB348-RHJBEAP7-en-6-20170411 45
-Djboss.server.base.dir=/home/student/JB348/labs/eap7/standalone
6. Monitor the Server Log

Using a new terminal window, use the following command to monitor the /home/student/
JB348/labs/eap7/standalone/log/server.log server log:
[standalone@workstation ~] tail -f /home/student/JB348/labs/eap7/standalone/log/\

server.log
7. Deploy the Migrated Application

To confirm that the server has been correctly migrated, deploy the application jboss-
helloworld-mdb-eap7, which is the same application as before, except that it has been
migrated to EAP 7 using the recommended Windup fix.
Note
There are several ways to migrate the MDB application to work with EAP
7. Another option is to remove the *-jms.xml file and either create the
queues in the EAP configuration or define the queues in the client using
@JMSDestinationDefinition.
In a new terminal window, start an EAP CLI session and then deploy the jboss-
helloworld-mdb-eap7.war application:

[standalone@localhost:9990 /] deploy \
/home/student/JB348/apps/jboss-helloworld-mdb-eap7.war

localhost:8080/jboss-helloworld-mdb-eap7. Confirm that the messages are
received by looking at the server logs in the terminal window tailing the log file located at /
home/student/JB348/labs/eap7/standalone/log/server.log.

message 1
message 4
message 5
message 3
message 2

46 JB348-RHJBEAP7-en-6-20170411
Solution
[student@workstation ~]$ lab migrating-lab grade
JB348-RHJBEAP7-en-6-20170411 47
Summary
• EJB 2 entity beans are no longer supported in EAP 7.
• JBossWeb is replaced in EAP 7 with Undertow.
• ActiveMQ Artemis replaces HornetQ as the messaging support provider.
• The EAP CLI can be used to migrate individual subsystems automatically using the migrate
command.
• Windup is an extensible rule-based tool that creates reports and automates aspects of an
application migration to EAP 7.
• The Windup reporting tool is useful for estimating the level of effort required in order to
migrate an application.
• The Server Migration tool is a simple solution for automating the migration of an EAP 6 server
to EAP 7.
• The Server Migration tool updates each subsystem to be compliant with the EAP 7 subsystems
and defaults, and removes any deprecated subsystems.
48 JB348-RHJBEAP7-en-6-20170411
TRAINING
CHAPTER 3
CONFIGURING A JBOSS EAP

CLUSTER
Overview
Goal Describe basic clustering concepts.
Objectives • Describe basic clustering concepts.
• Describe and configure Infinispan cluster services in EAP

7.
• Describe the JGroups Subsystem and its role in a server

cluster.
• Configure and deploy a highly available Singleton.

Sections • Reviewing Clustering Concepts (and Guided Exercise)
• Exploring Infinispan (and Guided Exercise)
• Exploring JGroups (and Guided Exercise)
• Deploying HA Singletons (and Guided Exercise)

Lab • Configuring a JBoss EAP Cluster
JB348-RHJBEAP7-en-6-20170411 49
Chapter 3. Configuring a JBoss EAP Cluster
Reviewing Clustering Concepts
Objectives
After completing this section, students will be able to describe basic clustering concepts.
Clustering Concepts in EAP 7

A cluster is a collection of EAP servers that communicate with each other to improve the
availability of services by providing:
• High Availability (HA): a service has a very high probability of being available.
• Scalability: a service can handle a large number of requests by spreading the workload across
multiple servers.
• Failover: if a service fails, the client continues processing its tasks on another cluster member.
• Fault Tolerance: a server can guarantee correct behavior even if failover occurs.
• Load Balancing: requests are spread out over the cluster so that no one server in the cluster
becomes over-burdened with connections.
The most common way to achieve scalability and high availability is to use a load balancer.
Previous releases of EAP required an external load balancer, such as Apache httpd, but EAP 7
now allows users to customize the Undertow subsystem to act as a front-end load balancer.
Important
Clustering is made available to an EAP instance by three subsystems: jgroups,
infinispan and modcluster. By default, the ha and full-ha profiles have these
subsystems enabled.
Note
In EAP 7, as in EAP 6, the clustering services start up on demand, and they also
shut down on demand, based on whether or not an application that is configured as
distributable is deployed on the servers.
For EAP 7, a cluster is a group of identically-configured servers that communicate with each
other to ensure that the cluster provides HA, failover and the other clustering capabilities. In a
managed domain, a cluster is actually a collection of servers in a server group, with each server
in the server group representing the nodes of the cluster.
50 JB348-RHJBEAP7-en-6-20170411
Clustering Concepts in EAP 7
In a managed domain, a cluster is a collection of servers. A cluster can consist of two or more
server groups, with all servers in the clustered server groups being the nodes of the cluster. As
the above diagram shows, you can have multiple clusters within a domain, and you can have
servers in a server group that do not form a cluster.
In the diagram Clustered Servers in Domain Mode there are three separate nodes. Each node
represents a single host. Each node also has a corresponding EAP host controller. Each host
controller defines multiple server instances, which are then organized into different server
groups. The advantage of using server groups is the ability to execute configuration changes or
deploy applications onto entire server groups.
In the diagram, the host controller running on Node 1 defines two servers, serverA and
serverB. Meanwhile, the host controller on Node 2 has three servers, serverC, serverD, and
serverE. Finally, the host controller on Node 3 defines three more servers, serverF, serverG,
and serverH. Across the cluster, there are three server groups defined, Server-Group1,
Server-Group2, and Server-Group3.
If the application helloWorld.war is marked as distributable and it is deployed on

Server-Group1, then it is clustered with all of the servers in Server-Group1. Therefore
if Node 3 were to fail, for example, then users are served the application from serverC or
serverA.
JB348-RHJBEAP7-en-6-20170411 51
Guided Exercise: Creating a Cluster
In this exercise, you will create a simple two-server cluster running in domain mode.
Eventually you are going to have a Domain Controller and two Host Controllers all running on
your student workstation. In reality, you probably would run these three controllers on separate
machines, so we are going to simulate separate machines by using subfolders named machine1,
machine2, and machine3.
In this lab, you are going to configure machine1 to run as the master controller. Also, you will
create and configure machine2 and machine3 as slaves connecting to machine1.
Resources
Files: /home/student/JB348/labs/create-cluster /home/
student/JB348/apps/cluster.war
version
Outcomes
You will be able to create and start a simple two-server cluster running in domain mode.
Before you begin

Use the following command to verify that an instance of EAP is installed in the /opt/ directory
and to download the server configuration files for this exercise:
[student@workstation ~]$ lab create-cluster setup
1. Create a New Domain Base Directory in the Workstation VM

Open a terminal window from the workstation VM (Applications > Favorites > Terminal)
and copy all of the contents from the folder /opt/jboss-eap-7.0/domain into a
new folder machine1 located in the lab directory /home/student/JB348/labs/
create-cluster/. This creates a folder machine1/, which contains three subfolders:
configuration, data, and tmp:
[student@workstation ~]$ cd /home/student/JB348/labs/create-cluster

[student@workstation create-cluster]$ mkdir machine1
[student@workstation create-cluster]$ cp -r /opt/jboss-eap-7.0/domain/* machine1
2. Configure Files in machine1 for a Domain Controller

2.1. Using the editor of your choice, open the host-master.xml file in the /home/
student/JB348/labs/create-cluster/machine1/configuration folder. This
host configuration file configures a domain controller that does not manage any local
servers.
2.2. Look at the following line at the beginning of the host-master.xml file:
<host xmlns="urn:jboss:domain:4.1" name="master">
This line configures the name of this host to be "master".
52 JB348-RHJBEAP7-en-6-20170411
2.3. There is only one interface defined in host-master.xml, named management.
...
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>
</interfaces>
...
It is assumed that the host machine running the domain controller is not hosting
servers. Consequently, it does not need to define a public network interface for the
server instances to accept user requests.
2.4. Any slaves must be configured to point to the IP address of the domain controller.
2.5. The labs are going to simulate multiple machines, and binding to 127.0.0.1 does not
make the domain controller on the machine1 folder visible to outside machines.
Modify the management interface's inet-address to bind to the IP address of

your workstation machine (172.25.250.254). The <interfaces> section of host-
master.xml appears as follows:
<interfaces>
</interface>
</interfaces>
Note
Instead of manually editing the XML file, it is also possible to specify the
jboss.bind.address.management property for the startup script.
2.6. Save your changes to host-master.xml and close the text editor.
2.7. Open the domain.xml in /home/student/JB348/labs/create-cluster/

machine1/configuration.
2.8. Inside of the messaging-activemq subsystem of the full-ha profile, edit the
<cluster> tag (line 1278):
<cluster password="${jboss.messaging.cluster.password:JBoss@RedHat123}" />
2.9. Save your changes to domain.xml.
3. Start the Domain Controller

Start the domain controller using the host-master.xml configuration file:
[student@workstation create-cluster]$ cd /opt/jboss-eap-7.0/bin

[student@workstation bin]$ ./domain.sh \
JB348-RHJBEAP7-en-6-20170411 53
-Djboss.domain.base.dir=/home/student/JB348/labs/create-cluster/machine1/ \
--host-config=host-master.xml
4. Create and Configure the host2 Host Controller

Create a new host controller with the following properties:
• Host Controller server: localhost
• Base directory: /home/student/JB348/labs/create-cluster/machine2
• Host name: host2
• Native interface port: 2999
• Management IP: 172.25.250.254
• Public IP: 172.25.250.254
• Private IP: 172.25.250.254
Creating and configuring a host controller is a repetitive task and can be scripted to make
the job easier. A custom native interface port is used to avoid port conflicts because the
domain controller from the previous lab is already bound to port 9999.
Open a new terminal window and run the following commands to create a host controller:

[student@workstation create-cluster]$ ./create-hc.sh localhost \
/home/student/JB348/labs/create-cluster/machine2 \
host2 2999 172.25.250.254 172.25.250.254 172.25.250.254
Note
The cluster communication by default use the JGroups technology. The JGroups
technology requires an interface named private. The create-hc.sh script
creates this new interface.
5. Start the host2 Host Controller

5.1. Start host2 using the host-slave.xml configuration file that has its management
interface bound to 172.25.250.254 on port 29999.
Run the following command from the /opt/jboss-eap-7.0/bin folder in a new

terminal window:

--host-config=host-slave.xml -Djboss.domain.master.address=172.25.250.254
54 JB348-RHJBEAP7-en-6-20170411
Note
The prefix of each log entry in the terminal window is either [HostController]
or the name of the server that caused the log event, which is either
[Server:server-one] or [Server:server-two] in your deployment.
5.2. Carefully review the log output in the terminal window of the host controller of
machine2. The log shows that the host controller connects to the master, and that
server-one and server-two have started.
[Host Controller] 16:42:57,307 INFO [org.jboss.as.host.controller]

(Controller Boot Thread) WFLYHC0148: Connected to master host controller at
remote://172.25.250.254:9999
[Host Controller] 16:42:57,367 INFO [org.jboss.as.host.controller] (Controller
Boot Thread) WFLYHC0023: Starting server server-one
5.3. Look in the terminal window of the domain controller for the following log entry
showing the slave connecting:
[Host Controller] 11:42:16,348 INFO [org.jboss.as.domain.controller] (Host

Controller Service Threads - 36) WFLYHC0019: Registered remote slave host
"host2", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)
6. Delete all servers

It is very common to delete all servers from a new host controller to create new servers with
custom names, groups, and port offset. Open a new terminal window and delete all servers
using the following commands:

[student@workstation create-cluster]$ ./delete-server.sh host2 \
server-one
server-two
7. Create and Configure the host3 Host Controller

Create a new host controller with the following properties:
• Host Controller server: localhost
• Base directory: /home/student/JB348/labs/create-cluster/machine3
• Host name: host3
• Native interface port: 3999
• Management IP: 172.25.250.254
• Public IP: 172.25.250.254
• Private IP: 172.25.250.254
JB348-RHJBEAP7-en-6-20170411 55
Run the following script to create a new host controller:
[student@workstation create-cluster]$ ./create-hc.sh localhost \

/home/student/JB348/labs/create-cluster/machine3 \
host3 3999 172.25.250.254 172.25.250.254 172.25.250.254
8. Start the host3 Host Controller

Run the following command from your /opt/jboss-eap-7.0/bin:

8.2. Carefully review the log output in the terminal window of the host controller for
machine2. The log shows that the host controller connects to the master, and that
server-one and server-two have started.

remote://172.25.250.254:9999
8.3. Look in the terminal window of the domain controller for the following log entry
showing the slave connecting:

"host3", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)
9. Delete all servers from host3

Open a new terminal window and delete all servers:

server-one
server-two
10. Create new servers

10.1. Create a new server on host2 host controller with the following properties:
• Name: my-server-one
• Server group: main-server-group
• Port offset: 0
56 JB348-RHJBEAP7-en-6-20170411
• Auto start: true
[student@workstation create-cluster]$ ./create-server.sh host2 \

my-server-one main-server-group 0 true
10.2.Create a new server on host2 host controller with the following characteristics:
• Name: my-server-two
• Server group: other-server-group
• Port offset: 150

my-server-two other-server-group 150 true
10.3.Create a new server on host3 host controller with the following characteristics:
• Name: my-server-three
• Server group: other-server-group

my-server-three other-server-group 1000 true
11. Deploy an application

11.1. Open a new terminal window and connect to the CLI tool:

[student@workstation bin]$ ./jboss-cli.sh --connect --user=jbossadm \
--password=JBoss@RedHat123 --controller=172.25.250.254:9990
11.2. Deploy the cluster application on the server group main-server-group:
[domain@172.25.250.254:9990 /] deploy /home/student/JB348/apps/cluster.war \

--server-groups=other-server-group
12. Verify the Servers are Running

12.1. On the workstation VM, open a web browser and navigate to
http://172.25.250.254:8080/cluster. The browser displays a 404 error page.
Since my-server-one does not belong to the other-server-group group, the
application was not deployed on this server.
12.2.In your web browser, navigate to http://172.25.250.254:8230/cluster. The

browser displays the default cluster application served by my-server-two.
JB348-RHJBEAP7-en-6-20170411 57
12.3.In your web browser, navigate to http://172.25.250.254:9080/cluster. The

browser displays the default cluster application served by my-server-three.
13. Test the Cluster

13.1. In your web browser, navigate to http://172.25.250.254:9080/cluster. Refresh
the page until you have the visitations count defined as 10.
13.2.Press Ctrl+C in the terminal window where you started the machine3 host to stop
new requests to this server.
13.3. In your web browser, refresh the page to confirm that the server is down.
13.4.In your web browser, navigate to http://172.25.250.254:8230/cluster. You

have not lost the visitations count and that the new value is defined as 11.

14.1. Run the following command from the workstation VM to grade the exercise:
[student@workstation ~]$ lab create-cluster grade
14.2.Press Ctrl+C in each terminal windows where you started the cluster instances of EAP
to stop the cluster.
58 JB348-RHJBEAP7-en-6-20170411
Exploring Infinispan
Exploring Infinispan
Objectives
After completing this section, students will be able to describe and configure Infinispan cluster
services in EAP 7.
Infinispan Cluster Services

The Infinispan subsystem provides caching support for JBoss EAP, facilitating the high
availability features of clustered servers.
In a clustered environment, similar data is replicated onto each node in the cluster. This data is
stored in a cache, and the caching mechanism and features are implemented by a framework
called Infinispan. In addition to being able to configure how EAP caches data, Infinispan also
provides the facilities to view runtime metrics for cache containers and caches.
A cache is defined within a cache container, or a repository for the caches. There are four
preconfigured cache containers in the ha and full-ha profiles:
• web: for session replication
• hibernate: for entity caching
• ejb: for stateful session bean replication
• server: for singleton caching
The web, hibernate and ejb caches are used by developers to cache Java components. In
clustering, the nodes use a cache in the cluster container configured for replicating objects
efficiently and effectively over a large cluster of nodes.
There are four different types of caches:
• Local: Entries are not distributed to the rest of the cache and are instead stored only on the
local node.
• Invalidation: Uses a cache store to store entries, pulling from the store when an entry needs
it.
• Replication: All entries are replicated on each node.
• Distribution: Entries are replicated to only some of the nodes.
Accordingly, there are four different pages in the Management Console for defining each
type of cache. These pages are locate in the Infinispan section of the Subsystem page in the
Management Console.
The following XML excerpt displays the default Infinispan configuration:
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster" default-cache="default"
module="org.wildfly.clustering.server">
JB348-RHJBEAP7-en-6-20170411 59
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist"
module="org.wildfly.clustering.web.infinispan">
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist"
module="org.wildfly.clustering.ejb.infinispan">
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query"
module="org.hibernate.infinispan">
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC"/>
</cache-container>
</subsystem>
The subsystem defines the four default cache containers: web, hibernate, ejb, and server. Each
cache container specifies the default-cache. For example, the hibernate cache container
uses the local-query cache, which maps to the local-cache.
Configure a new cache with the EAP CLI:

1. Create a cache container:
/subsystem=infinispan/cache-container=<container-name>:add
2. Add a replicated cache:
/subsystem=infinispan/cache-container=<container-name>/replicated-cache=<cache-
name>:add(mode=<mode>)
3. Set the default cache:
/subsystem=infinispan/cache-container=<container-name>:write-attribute(name=default-
cache,value=<cache-name>)
60 JB348-RHJBEAP7-en-6-20170411
Infinispan Architecture
Infinispan Architecture
Infinispan provides an implementation of JSR-107. As such, it provides services from the
javax.cache packages. Administrators need to understand how Infinispan works so that they
can troubleshoot and tune the service.
Figure 3.2: Infinispan Architecture
L1 Cache is also referred to as near cache in some caching products. It keeps a record of
frequently accessed cache queries in the local memory. It is only used in cases where the caching
mode is set to distributed. If it is not used, the Cache Manager communicates directly with the
Persistence Interface, or Store.
The Cache Manager hands a Cache Interface to the application, which then communicates
with the Cache. In general, unless a caching configuration differences at the wire level (TCP vs.
UDP, for instance) is required, a single Cache Manager will suffice across all deployed applications
on a server.
By using a Cache Container, it is possible to define multiple Cache Modes, and easily switch
between them when the need arises.
A Persistent Store is a back end for the cache. It can be in memory, a flat file, or a database.
In cases where it is left in memory, the store will not properly survive a system failure. Infinispan
communicates with the persistent store through the Persistence Interface, which depends
on the kind of store being used.
Configuring Infinispan
The Infinispan configuration is done by a desired profile. It means that all server groups that
belongs to a profile will have the Infinispan configured. The following steps are required to
configure the Infinispan subsystem:
1. Open the Management console.
2. Click Configuration either from the top menu or from the home screen.
3. In the first column, click Profiles. In the second column, click the desired profile. In the third
column, click Infinispan. The four preconfigured cache containers should be displayed.
JB348-RHJBEAP7-en-6-20170411 61
4. To create a new cache container, click Add in the fourth column. To manage a cache, click
the cache container and then click View.
5. Select the type of cache at the top of the page to view the configurations.
Demonstration: Configuring a Simple Cache

1. Open a terminal window from the workstation VM (Applications > Favorites > Terminal) and
run the following command to create the lab directory and verify that EAP is installed and
not currently running:
62 JB348-RHJBEAP7-en-6-20170411
Demonstration: Configuring a Simple Cache
[student@workstation ~]$ demo simple-cache setup
2. Start the domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/simple-cache/machine1/ \
3. Open a new terminal window and start host2 using the host-slave.xml configuration
file:

4. Open a new terminal window and start host3 using the host-slave.xml configuration
file:

5. Once the server finishes starting up, open a web browser and navigate to the management
console at http://172.25.250.254:9990. Use the following preconfigured
administrator credentials to log in:
• User Name: jbossadm
6. Click Configuration either from the top menu or from the home screen.
7. In the first column, click Profiles. In the second column, click ha. In the third column, click
Infinispan. In the fourth column, click ejb and then click View.
8. Make sure that Local Caches at the top of the page is selected.
9. Click Add to create a new cache. Name it local_ejb and click Save.
10. Under Transaction, click Edit. Update the Locking to OPTIMISTIC. With optimistic locking, a
resource is not actually locked when it is first accessed by a transaction.
11. Click Save to enable the new configuration and then click Back in order to return to the
main Configuration page.
12. Click ejb in the Cache Container column and click the down arrow next to View and then
click Container settings.
JB348-RHJBEAP7-en-6-20170411 63
13. Click Edit and update Default cache to local_ejb to define the new local cache as the default
cache for the ejb cache container.
14. Click Save to enable the new configuration.
15. Press Ctrl+C in each terminal windows where the cluster instances of EAP was started to
stop the cluster.
This concludes the demonstration.
Tuning Infinispan
Tuning Infinispan depends on each application that uses the cache. If the application works
with data that changes often, for example, set the Expiration and Eviction so that expired
entries are automatically purged, rather than waiting for a future get from the application to
trigger the purge. Eviction is similar to Garbage Collection where Expiration is like
marking objects as available for collection. Eviction defines the maxEntries attribute as a
power of two. If the attribute is not defined as a power of two, the next highest power of two is
selected. Thus, there is no point in setting maxEntries to 65. This bumps the maxEntries up
to 128, regardless.
If Infinispan needs to start some caches immediately when EAP starts, rather than waiting for an
application to use them, set the start mode of those caches to EAGER as opposed to the default,
which is LAZY. When using EAGER, use a Store as well, to mitigate the impact of slow startup
times.
References
Infinispan User Guide
http://infinispan.org/docs/stable/user_guide/user_guide.html
64 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Tuning Infinispan
Guided Exercise: Tuning Infinispan
In this exercise, you will tune the Infinispan subsystem to improve the cache performance.
Resources
Files: /home/student/JB348/labs/tuning-infispan /home/
student/JB348/apps/airports.war
Application URL: http://localhost:8080/airports, http://
localhost:8180/airports
Outcomes
You will be able to tune the Infinispan subsystem running in domain mode.
Before you begin

[student@workstation ~]$ lab tuning-infinispan setup
1. Start the cluster

1.1. Open a terminal window from the workstation VM (Applications > Favorites > Terminal)
and start the domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/tuning-infinispan/machine1/ \
Run the following command from your /opt/jboss-eap-7.0/bin folder in a new

terminal window:

interface bind to 172.25.250.254 on port 39999.

terminal window:

JB348-RHJBEAP7-en-6-20170411 65
2. Create a new Infinispan Replicated Cache

The airports application used in this lab requires a replicated cache to store the airports
around the world. The first time that an airport is searched, the cache is populated.
2.1. Open a new terminal window and connect to the CLI tool:

2.2. Navigate to the infinispan subsystem in the ha profile:
[domain@172.25.250.254:9990 /] cd /profile=ha/subsystem=infinispan
2.3. Create a new cache container named airport. The cache container must have the
jndi-name defined as infinispan/airports_container:
[domain@172.25.250.254:9990 subsystem=infinispan] ./cache-container=airport \

:add(jndi-name=infinispan/airports_container)
2.4. Infinispan synchronizes the cache with other instances of the cluster using the JGroups
transport. Set the timeout value, when obtaining locks for the transport, to one minute:
[domain@172.25.250.254:9990 subsystem=infinispan] cd cache-container=airport

[domain@172.25.250.254:9990 cache-container=airport] ./transport=TRANSPORT/ \
:add(lock-timeout=60000)
2.5. Create a synchronized replicated cache named airports. Presumably the replicated
cache must have the jndi-name defined as infinispan/airports_container/
airports.
[domain@172.25.250.254:9990 cache-container=airport] ./replicated-cache=\

airports:add(jndi-name=infinispan/airports_container/airports, mode=SYNC)
2.6. Reload the servers to enable the new cache:
[domain@172.25.250.254:9990 cache-container=airport] /:reload-servers
3. Deploy the airports application

Deploy the airports application on the server group airport-group:
[domain@172.25.250.254:9990 cache-container=airport] cd /
[domain@172.25.250.254:9990 /] deploy /home/student/JB348/apps/airports.war \
--server-groups=airport-group
4. Test the application

http://172.25.250.254:8080/airports to access the airports application.
66 JB348-RHJBEAP7-en-6-20170411
4.2. The airports application loads the details about an airport based on the ICAO code.
It is a four-character code designating aerodromes around the world. Fill the ICAO code
with sbbr and click Load Airport.
This is the first time the application has been accessed, so the cache must be loaded
before detailed information can be returned. Take a note about the time spent during
the first request.
4.3. Next, fill the ICAO code with krdu and click Load Airport. This time all of the airports
are available from the cache and the details about the airport is returned very quickly.
4.4. In your web browser, navigate to http://172.25.250.254:8180/airports. This is

the second node on the cluster. Fill the ICAO code with katl and click Load Airport.
Since you configured a replicated cache, the cache is already available to this node and
the details about this airport is returned quickly.
5. Tune the cache

Every time that the cluster is restarted, the first request must be delayed since the cache
will be loaded. To avoid this problem, configure the cache to save data to disk and to load the
cache while the server is booting.
5.1. Go back to the terminal that is running CLI and create a new path to persist the cache
file.
[domain@172.25.250.254:9990 /] /path=airport.cache.destination\
:add(path=/home/student/JB348/labs/tuning-infinispan)
5.2. Add a persistent file to the cache container that should be used during the server
booting with the following properties:
• path: airport-cache. This is the file that will persist the cache.
• relative-to: airport.cache.destination . This is the path to the cache file.
• passivation: false. False means that the cache store contains a copy of the
contents in memory, so writes to cache result in cache store writes.
• preload: true. True means that when the cache starts, data in the cache store is
preloaded into memory during the boot process.
• purge: false. False means that the cache store is not purged at startup time.
[domain@172.25.250.254:9990 /] /profile=ha/subsystem=infinispan/\
cache-container=airport/replicated-cache=airports/\
file-store=FILE_STORE:add(path=airport-cache, \
relative-to=airport.cache.destination,\
passivation=false, preload=true, purge=false)
5.3. Reload the servers to enable the new configuration:
[domain@172.25.250.254:9990 /] :reload-servers
JB348-RHJBEAP7-en-6-20170411 67
6. Test the new configuration

http://172.25.250.254:8080/airports. Fill the ICAO code in with kjfk.
Since this is the first time that the cache is being accessed after the tuning, it takes
extra time to populate the cache and persist it.
6.2. Go back to terminal that is running CLI and reload the cluster:
6.3. Go back to the web browser and refresh the http://172.25.250.254:8080/

airports page. Fill the ICAO code with eglc.
The response time is much faster since the cache was loaded during the booting
process.

[student@workstation ~]$ lab tuning-infinispan grade
7.2. Press Ctrl+C in each terminal windows where you started the cluster instances of EAP
68 JB348-RHJBEAP7-en-6-20170411
Exploring JGroups
Exploring JGroups
Objectives
After completing this section, students will be able to describe the JGroups Subsystem and its
role in a server cluster.
JGroups Overview
The JGroups Subsystem provides all communication mechanisms allowing servers in a cluster
to communicate with one another.
JBoss EAP 7 ships with JGroups and includes configurations for cluster communications in the
ha and full-ha profiles which provide a good baseline example for clustering.
JGroups itself uses the concepts of nodes and clusters. A cluster is, to put it simply, a collection
of nodes. A node broadly maps to an EAP server. Individual nodes can be part of multiple
clusters, provided the node is running multiple EAP server instances. The following diagram
outlines nodes in a cluster:
Figure 3.6: JGroups Cluster
JGroups in EAP 7 uses an address and port to define the nodes in a cluster. If a node needs a
cluster address that does not exist, JGroups will create a new cluster to accommodate it. This
simplifies cluster configuration immensely, since the servers themselves create clusters as
needed.
In EAP 7, the JGroups sockets require a new interface named private, as listed on the sockets
section from the desired profile:
JB348-RHJBEAP7-en-6-20170411 69
<socket-binding name="jgroups-mping" interface="private" port="0" multicast-

address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
<socket-binding name="jgroups-tcp" interface="private" port="7600"/>
<socket-binding name="jgroups-tcp-fd" interface="private" port="57600"/>
<socket-binding name="jgroups-udp" interface="private" port="55200" multicast-
address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
<socket-binding name="jgroups-udp-fd" interface="private" port="54200"/>
<socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-
port="23364"/>
The objective for the new interface is to separate the network traffic used by the cluster from the
network traffic used by the application.
JGroups is designed to ensure reliable group communication. Individual nodes can send and
receive messages from all or some of the other members of the group. As nodes join and leave
the cluster, JGroups tracks and informs all nodes of changes in cluster membership, and JGroups
provides a view of the nodes of a cluster at any given time. JGroups also handles retransmission
in the case of a delivery failure, elimination of duplicate messages, and orders the messages so
that nodes are getting the right messages at the right time.
Note
All cluster communication goes through JGroups. Infinispan manages its distributed
cluster via JGroups. This gives an administrator a single configuration point to manage
how a cluster communicates.
JGroups Architecture
JGroups consists of three parts:
• Channel: A channel provides a link to the JGroups system. A client joins a group by
connecting the channel to a group and leaves it by disconnecting. Messages sent over the
channel are received by all group members that are connected to the same group.
• Building blocks: Channels are simple socket-like constructs that does not provides a
sophisticated interface. JGroups offers building blocks that provide more sophisticated APIs
on top of a Channel. Building blocks either create and use channels internally, or require an
existing channel to be specified when creating a building block.
• Protocol stack: The protocol stack is responsible for translating messages to transmit
them across the network to other nodes.
Configure JGroups
EAP is preconfigured with two JGroups stacks:
1. UDP: the nodes in the cluster use User Datagram Protocol (UDP) multicasting to
communicate with each other. This is the default stack.
2. TCP: the nodes in the cluster use Transmission Control Protocol (TCP) to communicate with
each other.
Users can use one of these preconfigured stacks, or can define and use a new stack that suits the
specific needs of the environment. By default, the UDP protocol is used to communicate between
70 JB348-RHJBEAP7-en-6-20170411
Configure JGroups
clustered nodes in the default ee JGroups channel. The following EAP CLI command adjusts the
ee JGroups channel to use a tcp stack instead of UDP:
/subsystem=jgroups/channel=ee:write-attribute(
name=stack,value=tcp)
Also, it is important to define the default stack attribute to use tcp:
/subsystem=jgroups:write-attribute(
name=default-stack,value=tcp)
By default, the TCP stack uses multicast for discovering other members of a cluster. Users can
further customize the TCP stack by changing the protocol to either TCPPING or TCPGOSSIP.
• TCPPING: a protocol that uses a static list to define the cluster members and uses unicast as
an alternative to multicast. The following configurations are specific to this protocol:
◦ initial_hosts: a list of the hosts that are available and known to look up for cluster
membership.
◦ port_range: the range that the protocol uses to search for hosts based on the initial port.
For example, a port range of two on an initial port of 7600 results in the TCPPING protocol
searching for a viable host on ports 7600 and 7601 to be added to the membership.
• TCPGOSSIP: discovers members of a cluster by using an external gossip router.
The following configuration is an example of a full TCP cluster:
<stack name="tcpping">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="TCPPING">
<property name="initial_hosts">
servera[7600],servera[7700],serverb[7600],serverb[7700]
</property>
<property name="port_range">
10
</property>
</protocol>
<protocol type="MERGE3"
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD" />
<protocol type="VERIFY_SUSPECT" />
<protocol type="pbcast.NAKACK2" />
<protocol type="UNICAST3" />
<protocol type="pbcast.STABLE" />
<protocol type="pbcast.GMS" />
<protocol type="MFC" />
<protocol type="FRAG2" />

</stack>
In MERGE3, all members periodically send an INFO message with their address (UUID),
logical name, physical address and ViewId.
Failure detection protocol based on a ring of TCP sockets created between cluster members.
JB348-RHJBEAP7-en-6-20170411 71
Failure detection based on heartbeat messages.

Verifies that a suspected member is really dead by pinging that member one last time
before excluding it.
The pbcast.NAKACK protocol provides reliable delivery and First In First Out (FIFO)
properties for messages sent to all nodes in a cluster.
UNICAST3 provides reliable delivery and FIFO properties for point-to-point messages
between one sender and one receiver.
The pbcast.STABLE protocol garbage collects messages that have been seen by all members
of a cluster.
Responsible for managing the group membership.
Flow control based on a credit based system.
Fragment large messages into smaller ones. Send the smaller ones, and at the receiver side,
assemble them into larger messages again.
Tuning JGroups
Tuning JGroups depends on each environment. Here are a few key notes about tuning the
JGroups:
• When running multiple clusters from a single node, change the port and, preferentially, the
multicast address to keep cluster communications separate.
• JGroups uses sized packets to perform communications. The packet size can be controlled in
the settings for the protocol, and should be set to the same size as the maximum sizes defined
at the operating system level. This is one of a very few places where the operating system
can also be tuned to better support EAP clusters. Either way, the sizes should match, if at all
possible.
• Long JVM Garbage Collection (GC) may impact the FD (Failure Detection) timeout and retry.
The GC may need to be tuned for shorter GC cycles or a longer FD timeout.
• The default TCP stack included with JBoss EAP 7 still uses MPING for server discovery, which
runs over UDP. To completely remove UDP from the stack, replace MPING with TCPPING and
configure appropriately.
JGroups in the Cloud

Some cloud providers charge less for traffic over internal IP addresses compared to public IP
addresses. In fact, some cloud providers charge nothing for traffic over the internal network.
In these circumstances, it's advantageous to configure the group communications in such way
that replication traffic is sent via the internal network. However, the administrator may not know
which internal IP address will be assigned.
JGroups, the underlying group communication library, provides a way for users to bind to a
type of address rather than to a specific IP address. Administrators can configure bind_addr
property in JGroups configuration file, or the -Djgroups.bind_addr system property to a
keyword rather than a dotted decimal or symbolic IP address:
• GLOBAL: pick a public IP address. This should be avoided due to replication traffic.
• SITE_LOCAL: use a private IP address, for instance 192.168.x.x. This avoids charges for
bandwidth from providers who do not charge for internal network traffic.
72 JB348-RHJBEAP7-en-6-20170411
Troubleshooting JGroups with mcast
• LINK_LOCAL: use a 169.x.x.x, 254.0.0.0 address. This works only within one box, for
instance, in the examples provided in this section, with two clusters on one machine.
• NON_LOOPBACK: use the first address found on an interface found on an active interface,
which is not a 127.x.x.x address.
When using JGroups with Amazon EC2 (a service provider supported by Red Hat OpenShift), it is
required to include EC2-specific configurations. The three key ones are:
• jgroups.s3.access_key: The Amazon S3 access key used to access an S3 bucket.
• jgroups.s3.secret_access_key: The Amazon S3 secret key used to access an S3 bucket.
• jgroups.s3.bucket: Name of the Amazon S3 bucket to use. Must be unique and must
already exist.
Troubleshooting JGroups with mcast

Some cluster environments do not support multicast and for this reason the nodes do not form a
cluster.
There are two applications that can be used to detect this: McastReceiverTest and
McastSenderTest.
The McastReceiverTest listens for all multicast messages from a specific IP and port. Use the
following command to start the program:
# java -cp jgroups-3.6.8.Final-redhat-2.jar org.jgroups.tests.McastReceiverTest -
mcast_addr 230.0.0.4 -port 45688
The JGroups jar file can be found on JBOSS_HOME/modules/system/layers/base/

org/jgroups/main/ folder.
The multicast address that JGroup should use for listening messages.
The multicast port that JGroup should use for listening messages.
The McastSenderTest sends a multicast message to a specific ip and port. Use the following
command to start the program:
# java -cp jgroups-3.6.8.Final-redhat-2.jar org.jgroups.tests.McastSenderTest -
mcast_addr 230.0.0.4 -port 45688
The multicast address that JGroup should use for sending a message.
The multicast port that JGroup should use for sending a message.
If a message is sent by the McastSenderTest application and is not displayed by the
McastReceiverTest, it means that multicast is not allowed in that environment.
JB348-RHJBEAP7-en-6-20170411 73
Guided Exercise: Troubleshooting JGroups
In this exercise, you will troubleshoot an issue with JGroups in an EAP cluster.
Resources
Files: /home/student/JB348/labs/troub-jgroups, /home/
student/JB348/apps/cluster.war, /tmp/new-tcp-
stack.cli
Application URL: http://localhost:9080/cluster
Outcomes
You will able to troubleshoot a JGroups problem using the mcast program.
Before you begin

[student@workstation ~]$ lab troub-jgroups setup
1. Configure the firewall

This guided exercise starts a cluster using the workstation VM as domain controller and
load balancer, and server A and server B VM as slave controllers. In addition, a firewall is
configured to allow communication in the cluster between its members.
1.1. Open a terminal window from the workstation VM (Applications > Favorites > Terminal)
and apply the following firewall rules:
• Port: 9990/tcp - used to create a socket for the management interface.
• Port: 9999/tcp - used to create a socket for the management native interface.
• Port: 9080/tcp - used by the load balancer.
[student@workstation ~]$ sudo firewall-cmd --permanent --zone=public \

--add-port=9990/tcp

--add-port=9999/tcp

--add-port=9080/tcp
1.2. Reload the firewall rules to enable the new configuration:
[student@workstation ~]$ sudo firewall-cmd --reload
1.3. Access the servera VM using the ssh command:
74 JB348-RHJBEAP7-en-6-20170411
[student@workstation ~]$ ssh servera
Apply the following firewall rules:
• Port: 8080/tcp - used to create a socket responsible for serving the application
requests using the HTTP protocol.
• Port: 8009/tcp - used to create a socket responsible for serving the application
requests using the AJP protocol.
• Port: 7600/tcp - used by JGroups to recognize the members that belongs to a cluster
while JGroups is configured to use TCP instead of UDP.
• Port: 57600/tcp - This port is used by JGroups to detect failures based on sockets
generating notifications if a member fails.
[student@servera ~]$ sudo firewall-cmd --permanent --zone=public \

--add-port=8080/tcp

--add-port=8009/tcp

--add-port=7600/tcp

--add-port=57600/tcp
[student@servera ~]$ sudo firewall-cmd --reload
1.5. Access the serverb VM using the ssh command:
[student@servera ~]$ ssh serverb
Apply the same rules from server A:
[student@serverb ~]$ sudo firewall-cmd --permanent --zone=public \

--add-port=8080/tcp

--add-port=8009/tcp

--add-port=7600/tcp
JB348-RHJBEAP7-en-6-20170411 75

--add-port=57600/tcp
[student@serverb ~]$ sudo firewall-cmd --reload
2. Start and configure a load balancer

The setup script created the load balancer configuration in the /home/student/JB348/
labs/troub-jgroups/lb folder on workstation VM. Start the load balancer with the
standalone-ha.xml and a port offset of 1000 to avoid port clashes with the domain
controller running on the workstation. Because the load balancer is going to be the
entry point for the application, it must be configured to listen on the public IP of the
workstation (172.25.250.254).
2.1. Open a new terminal window from workstation and run the following command to
start the load balancer:

-Djboss.server.base.dir=/home/student/JB348/labs/troub-jgroups/lb \
-Djboss.bind.address=172.25.250.254 -Djboss.socket.binding.port-offset=1000 \
-c standalone-ha.xml
2.2. Launch the EAP CLI in a new terminal window and connect to the load balancer instance
on workstation.
In a new terminal window on workstation, start the EAP CLI and connect to the load
balancer:

[student@workstation bin]$ ./jboss-cli.sh --connect --controller=localhost:10990
2.3. Configure the modcluster subsystem to act as a front-end load balancer. Set a unique
password for the advertise-security-key.
[standalone@localhost:10990 /] /subsystem=modcluster/mod-cluster-config=\
configuration:write-attribute\
(name=advertise-security-key, value=redhat)
2.4. Configure the mod_cluster filter. Advertise the load balancer using the modcluster
socket-binding and use the HTTP protocol for the management socket binding. Ensure
that the security-key attribute matches the advertise-security-key you
configured in the previous step.
[standalone@localhost:10990 /] /subsystem=undertow/configuration=\
filter/mod-cluster=modcluster:add\
(management-socket-binding=http, advertise-socket-binding=modcluster,\
security-key=redhat)
76 JB348-RHJBEAP7-en-6-20170411
2.5. Bind the modcluster filter to the undertow default-server.
[standalone@localhost:10990 /] /subsystem=undertow/server=\
default-server/host=default-host/filter-ref=modcluster:add
2.6. Reload the load balancer configuration and exit from CLI:
[standalone@localhost:10990 /]:reload
[standalone@localhost:10990 /] exit
3. Start and configure the domain controller

3.1. Start the domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/troub-jgroups/machine1/ \
3.2. In a new terminal window on workstation, start the EAP CLI and connect to the
domain controller:

[student@workstation bin]$ ./jboss-cli.sh -c --controller=172.25.250.254:9990
3.3. Configure the mod_cluster subsystem. By default, EAP is set up to advertise its status
to load balancers using UDP multicasting. Disable advertising in the mod_cluster
subsystem for the ha profile.
[domain@172.25.250.254:9990 /] /profile=ha/subsystem=modcluster\
/mod-cluster-config=configuration/\
:write-attribute(name=advertise,value=false)
3.4. Because you have disabled advertising, you must configure the back-end EAP
nodes with a list of proxies (load balancers). Configure the EAP back-end nodes
to communicate with the load balancer running on the workstation VM. Add
an outbound socket binding that points to the load balancer IP address and port
(172.25.250.254:9080).
[domain@172.25.250.254:9990 /] /socket-binding-group=ha-sockets\
/remote-destination-outbound-socket-binding=lb:\
add(host=172.25.250.254,port=9080)
3.5. Next, add the proxies to the mod_cluster configuration:
[domain@172.25.250.254:9990 /] /profile=ha/subsystem=modcluster\
/mod-cluster-config=configuration:list-add(name=proxies,value=lb)
3.6. Deploy the cluster.war application:
JB348-RHJBEAP7-en-6-20170411 77

--server-groups=cluster-group
4. Start the two host controllers

4.1. Open a terminal window from workstation VM and access the servera VM using the
ssh command:
Start the host controller:
[student@servera ~]$ cd /opt/jboss-eap-7.0/bin

[student@servera bin]$ ./domain.sh \
4.2. Open a terminal window from the workstation VM and access the serverb VM using
the ssh command:
[student@workstation ~]$ ssh serverb
[student@serverb ~]$ cd /opt/jboss-eap-7.0/bin

[student@serverb bin]$ ./domain.sh \
5. Test the cluster

On the workstation VM, open a web browser and navigate to
http://172.25.250.254:9080/cluster. You will see the cluster application. Refresh
the page until the number of visitations increases and that all requests are being handled by
the same node.
If your requests are being handled by cluster-one server, press Ctrl+C in the terminal
window from servera, or press Ctrl+C in the terminal window from serverb to stop the
server that is handling the requests.
Refresh the page again and notice that the cluster is not working properly. The number of
visitations does not persist, as it would in a normally functioning cluster. Instead, the number
of visits is reset to "1".
Press Ctrl+C in the terminal window from the other node to stop the cluster.
6. Check that JGroup is not working

The problem with the cluster is that the nodes are not communicating correctly due to
misconfigured JGroups. JGroups, by default, communicates using multicast and multicast is
not allowed in this environment.
6.1. Open a new terminal window from workstation and access the servera VM.
78 JB348-RHJBEAP7-en-6-20170411
6.2. JGroups provides a tool to verify whether multicast is working, given an environment
listening for all multicast messages. The communication between the nodes in a JBoss
EAP cluster uses the 230.0.0.4 address on the 45688 port using the udp protocol.
You should start a client that will listen for all messages that are being send to this
address:
[student@servera ~]$ cd /opt/jboss-eap-7.0/modules/system

[student@servera system]$ cd layers/base/org/jgroups/main/
[student@servera main]$ java -cp jgroups-3.6.8.Final-redhat-2.jar \
org.jgroups.tests.McastReceiverTest -mcast_addr 230.0.0.4 -port 45688
6.3. Open a new terminal window on workstation to access the servera VM.
6.4. Start a client that will write a message using multicast:
[student@servera ~]$ cd /opt/jboss-eap-7.0/modules/system

[student@servera system]$ cd layers/base/org/jgroups/main/
[student@servera main]$ java -cp jgroups-3.6.8.Final-redhat-2.jar \
org.jgroups.tests.McastSenderTest -mcast_addr 230.0.0.4 -port 45688
6.5. Enter your name and verify that it was displayed in the terminal waiting for the
messages:
> Your Name
The multicast is working for the same node. Type exit to quit the client.
JGroups also provides a tool to send a message using multicast. Start a client that
writes a message using the same address and port used by JBoss EAP:
[student@serverb ~]$ cd /opt/jboss-eap-7.0/modules/system

[student@serverb system]$ cd layers/base/org/jgroups/main/
[student@serverb main]$ java -cp jgroups-3.6.8.Final-redhat-2.jar \
org.jgroups.tests.McastSenderTest -mcast_addr 230.0.0.4 -port 45688
6.7. Enter your name and verify that it was not displayed in the terminal waiting for the
messages. This test proves that the multicast is not working between servera and
serverb.
JB348-RHJBEAP7-en-6-20170411 79
7. Fix the cluster

7.1. The cluster must define a new TCP stack configuration. TCP, unlike UDP, can use
the more reliable unicast method of communication. Open the file/tmp/new-tcp-
stack.cli on the workstation VM and review the commands listed in it.
Edit the initial_hosts property and replace the values with the host name and ports
of the two EAP server instances that are part of the cluster.
..."initial_hosts":add(value="servera[7600],serverb[7600]")
7.2. Execute the EAP CLI script file on the domain controller.

[student@workstation bin]$ ./jboss-cli.sh --connect \
--controller=172.25.250.254:9990 --file=/tmp/new-tcp-stack.cli
8. Start the host controllers and test to verify that the nodes are able to communicate. After
stopping one node, the number of visitations is not restarted.

[student@workstation ~]$ lab troub-jgroups grade
80 JB348-RHJBEAP7-en-6-20170411
Deploying HA Singleton Applications
Deploying HA Singleton Applications
Objectives
After completing this section, students will able to configure and deploy a high availability
application.
The need for cluster singletons

A singleton is a popular software development design pattern in which there is a single shared
instance of an object for the whole application. The usual implementation for the singleton
design pattern creates one instance for each cluster member. But this may have unintended
consequences for an application, such as data consistency issues.
Sometimes the application logic requires that only one instance of an object is running for the
whole cluster. A developer could extract this instance to run as a service that is deployed into
a single non-clustered EAP instance that is accessed by a clustered application, but then the
service would become a single point of failure.
Many developers believe a @Singleton EJB works correctly as a clustered singleton but this is
not true by the EJB specification. It states that each JVM in a distributed application server gets
one instance. All ways to implement a singleton using only standard JVM or JEE features creates
one instance per JVM, that is, one instance for each EAP server in a cluster.
When an application needs high availability and must work across the cluster, developers and
EAP administrators have to work together to extract the singleton parts from the clustered
application. They must adapt the application to use of the following proprietary EAP 7
approaches:
• Singleton deployments (similar to the feature from EAP 5)
• Singleton services (enhanced version of the EAP 6 feature)
Both approaches allow an application to work as an active-passive HA application inside an EAP

cluster, but they differ in configuration details and the changes required to application packaging
and source code.
The singleton subsystem

Both singleton deployments and singleton services are managed by the singleton subsystem.
It employs an Infinispan cache to register all known singleton deployments and singleton services
and defines which cluster member runs each application. The EAP server instance that runs a
singleton application is called the master server for that application.
The singleton subsystem can be configured with different election policies that define the
master. Two kinds of election policies are provided by EAP 7:
• simple: the first node to join the cluster runs the singleton application.
• random: a random node is selected to run the singleton application.
An election policy can optionally specify a preferred server which, when available, will be the
master for ALL singleton applications under that policy. The policy refers to the node name as
specified by the jboss.node.name system property.
JB348-RHJBEAP7-en-6-20170411 81
The default EAP 7 configuration files provide a simple election policy named default with no
preferred server. This policy is shown by the following listing:
...
<subsystem xmlns="urn:jboss:domain:singleton:1.0">
<singleton-policies default="default">
<singleton-policy name="default" cache-container="server">
<simple-election-policy/>
</singleton-policy>
</singleton-policies>
</subsystem>
...
The following commands show how to create a new election policy named custom, of type
random, which prefers the server named servera1:
/subsystem=singleton/singleton-policy=custom/election-policy=random:add()
/subsystem=singleton/singleton-policy=custom/election-policy=random:list-add(\
name=name-preferences, value=servera1)
If the master server fails, the singleton subsystem runs a new election for all singleton
applications that were using the failed server as their master. These applications are then
restarted in new master servers. Each singleton application has to provide their own means to
recover or recreate in-memory data lost in the failed master server.
A potential issue with a singleton application is when there is a network partition, also known
as the split-brain scenario: Two sets of servers from the same cluster cannot connect to each
other, but servers from one set have no issue connecting to servers from the same set. Each set
of servers think all servers from the other set failed and continue to work as a surviving cluster.
A split-brain scenario has two (or more) independent clusters where there should be a single
cluster. This can quickly lead to data consistency issues. To prevent that, an election policy can
specify a quorum; that is, the minimum required number of cluster members. If a quorum is not
reached, all remaining cluster members are shut down.
To configure a quorum of three servers, use the following command:
/subsystem=singleton/singleton-policy=custom:write-attribute(name=quorum, value=3)
The quorum should be at least N/2+1 where N is the anticipated total number of cluster
members.
Singleton deployments
Singleton deployments are similar to HASingletonDeployer from EAP 5 and earlier. There was
no similar feature in EAP 6. It is a way to mark a deployment as a cluster-wide singleton without
the need to use proprietary EAP 7 APIs.
An application package is considered to be a singleton deployment if it contains the proprietary

deployment descriptor /META-INF/singleton-deployment.xml. This file refers to the
election policy to be used for the singleton application, and the following example refers to the
custom policy from the previous example:
82 JB348-RHJBEAP7-en-6-20170411
Singleton services
<singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0" policy="custom"/>
Although this approach does not require an application to use EAP 7 proprietary APIs, it still
requires the original clustered application to access the extracted singleton application, for
example, using remote EJB calls or JMS.
Singleton services
Singleton services are implemented the same way as internal EAP services, that is, their source
code uses WildFly Core APIs. Although more intrusive than singleton deployments, singleton
services provide the following advantages in very specific use cases:
• The election policy can be defined by the application, without the need to configure the
singleton subsystem.
• It allows EAP modules to start cluster-wide singleton services similar to the old JBossMQ from
EAP 4. That is, it allows an EAP module to work as an active-passive clustered service.
Teaching students how to program a singleton service is outside the scope of this book.
References
For more information about HA Singletons, see the upstream documentation:
Wildfly 10 HA Singleton Features

https://docs.jboss.org/author/display/WFLY10/HA+Singleton+Features
For information about singleton EJBs and clustered environments:
JSR-345: EJB 3.2 specification

https://jcp.org/aboutJava/communityprocess/final/jsr345/index.html
For information about how to develop singleton services:
EAP 7 Developing EJB Applications

https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-
platform/7.0/developing-ejb-applications/developing-ejb-applications
JB348-RHJBEAP7-en-6-20170411 83
Guided Exercise: Deploying an HA Singleton
In this exercise, you will implement deploy an HA Singleton.
Resources
Files: /home/student/JB348/labs/ha-singleton /home/
student/JB348/apps/information-desktop.jar /
home/student/JB348/apps/information-singleton-
ejb.jar
Application URL: NA
Outcomes
You should be able to configure a HA Singleton application in a cluster.
Before you begin

[student@workstation ~]$ lab ha-singleton setup

Open a terminal window from the workstation VM (Applications > Favorites > Terminal) and
start the domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/ha-singleton/machine1/ \
2. Configure the HA Singleton

The information-singleton-ejb.jar application is available in just one instance from
the cluster. However, it is preferred for applications to have high availability, meaning that if
a node that is handling this application dies, then other nodes star serving the application
automatically.
2.1. The application is configured to request an election policy named custom. Open a new
terminal window and connect to CLI to create the election policy.

[student@workstation ~]$ ./jboss-cli.sh --connect --user=jbossadm \
2.2. Create a new election policy named custom. The election policy uses a cache container
named server. This cache is responsible for registering singleton provider candidates.
[domain@172.25.250.254:9990 /] /profile=ha/subsystem=singleton/ \
singleton-policy=custom:add(cache-container=server)
84 JB348-RHJBEAP7-en-6-20170411
2.3. The election policy must be configured to select a random node to run the singleton
application. Configure the custom election policy to achieve this goal.
[domain@172.25.250.254:9990 /] /profile=ha/subsystem=singleton/ \
singleton-policy=custom/election-policy=random:add()
2.4. It is possible to define a preferred server to run the singleton application. Configure the
election policy to prefer the cluster-two server:
[domain@172.25.250.254:9990 /] /profile=ha/subsystem=singleton/\
singleton-policy=custom/election-policy=random\
:list-add(name=name-preferences, value=cluster-two)
With this configuration, if the cluster-two server is available on the cluster, it is

responsible for handling new requests for the application.
3. Deploy the HA-singleton Application

Deploy the /home/student/JB348/apps/information-singleton-ejb.jar
application into the cluster-group server group:
[domain@172.25.250.254:9990 /] deploy \
/home/student/JB348/apps/information-singleton-ejb.jar \
Exit the CLI application:
[domain@172.25.250.254:9990 /] exit
4. Configuring security
In EAP 7, a lookup to a remote EJB requires authentication. The information-
desktop.jar client application is configured to authenticate using the appsingleton
user name with password defined as JBoss@RedHat123.
Create credentials for the host2 node:
[student@workstation bin]$ ./add-user.sh -a -u appsingleton -p JBoss@RedHat123 \

-dc /home/student/JB348/labs/ha-singleton/machine2/configuration/
Also create the credentials for the host3 node:
[student@workstation bin]$ ./add-user.sh -a -u appsingleton -p JBoss@RedHat123 \

-dc /home/student/JB348/labs/ha-singleton/machine3/configuration/
5. Start the Host Controllers

interface bound to 172.25.250.254.

JB348-RHJBEAP7-en-6-20170411 85
Wait until the startup process finishes. The log output shows that this node is selected
to serve the singleton:
...OUTPUT OMITED...
[Server:cluster-one] 00:23:40,092 INFO [org.wildfly.clustering.server]
(notification-thread--p1-t1) WFLYCLSV0001: This node will now operate as
the singleton provider of the jboss.deployment.unit."information-singleton-
ejb.jar".FIRST_MODULE_USE service
...OUTPUT OMITED...
interface bind to 172.25.250.254.

terminal window:

Wait until the startup process finishes. The log output shows that this node is now
selected to serve the singleton. The reason for the change is that host3 is the host
controller responsible for the cluster-two server. The cluster identified that a
preferred server is available on the cluster and changed the node that will operate as
the singleton provider.
Also observe in the log output from host2 that the singleton will no longer operate as
the singleton provider.
...OUTPUT OMITED...
[Server:cluster-one] 00:30:44,031 INFO [org.wildfly.clustering.server]
(thread-17,ee,host2:cluster-one) WFLYCLSV0002: This node will no longer operate
as the singleton provider of the jboss.deployment.unit."information-singleton-
ejb.jar".FIRST_MODULE_USE service
...OUTPUT OMITED...
6. Test the Singleton Using a Client

6.1. The information-desktop.jar client application requests informations about the
HA-singleton application and displays on the screen. Open a terminal window from the
workstation VM and run the application:
[student@workstation ~]$ java -jar \

/home/student/JB348/apps/information-desktop.jar
The following output is expected:
###############################################################################
# Base dir: /home/student/JB348/labs/ha-singleton/machine3/servers/cluster-two
# Node name: host3:cluster-two
# Host name: workstation
86 JB348-RHJBEAP7-en-6-20170411
###############################################################################
As expected, the cluster-two server was responsible for the request.
6.2. Run the application multiple times. All responses should have the same information.
6.3. Stop the host3 pressing Ctrl+C in the terminal window that started the host.
6.4. Run the client application. Since the cluster-two server is not more available, the
cluster-one is responsible for handling the new requests.
Note
The client application is configured to load balancer the requests between
nodes. Since you stopped the host3, you should see the following exception
before the information:
WARN: Could not register a EJB receiver for connection to

172.25.250.254:8180
java.lang.RuntimeException: java.net.ConnectException: Connection
refused

[student@workstation ~]$ lab ha-singleton grade
7.2. Press Ctrl+C in the terminal windows where you started the cluster instances of EAP
JB348-RHJBEAP7-en-6-20170411 87
Lab: Configuring a JBoss EAP Cluster
In this lab, you will create a managed domain and a load balancer.
Resources
Files: /home/student/JB348/labs/create-cluster, /home/
version
Outcomes
You should be able to start a domain controller and a load balancer on the workstation VM
and run a host controller on both server A and server B. The final solution should be in line
with the following architecture with regards to the host controller and the domain controller.
Before you begin

and to download the required files for this exercise:
[student@workstation ~]$ lab configure-cluster setup
88 JB348-RHJBEAP7-en-6-20170411
1. To get started creating the domain controller, copy files from JBOSS_HOME/domain into
the lab directory at /opt/domain on the workstation. Set the owner of the /opt/domain
directory to user jboss.
2. The EAP instance on workstation is the domain controller, and exposes the management
interface to an internal network. The network where all servers are connected to is the
172.25.250.X network. Other network interfaces should not be exposed to guarantee that
external host controllers may not get sensitive information from the domain controller.
Update the address of the management interface for the domain controller to point to the
workstation's IP address (172.25.250.254) using the host-master.xml configuration
file. Remember to unlock the 9990/tcp and 9999/tcp ports to allow the communication
between the domain controller and the host controllers:
3. Because the domain controller will run an application with high availability features,
including the messaging subsystem, some extra requirements are needed. The domain
controller is responsible for providing security information to allow server instances to be
part of a clustered environment, for all subsystems.
The messaging subsystem requires authentication to exchange data among cluster

members, and the credentials are declared in the domain.xml file. The details about the
subsystem are explained later, but for the environment to function correctly, the cluster
password must be declared at the domain controller configuration file.
Update domain.xml on workstation to set the cluster password to JBoss@RedHat123.
3.1. As the jboss user, open the /opt/domain/configuration/domain.xml file on

workstation .
<cluster> tag (line 1278).
4. Start the domain controller on the workstation.
4.1. In your terminal window, change directories to /opt/jboss-eap-7.0/bin:
4.2. To start the domain controller using the host-master.xml file in your /opt/
domain/ folder.
5. An instance of EAP is already installed on both server A and server B. Create a new host
controller with the following characteristics using the /home/student/JB348/labs/
configure-cluster/create-hc.sh script file:
• The base directory on server A is /opt/domain and sets the owner as jboss.
• Set the name of the host to servera.
• Use the IP address of Server A, 172.25.250.10, for the management, public, and private
interface.
• Set the host controller to connect to the domain controller using the login jbossadm
and the password JBoss@RedHat123. You can generate the password using the base64
algorithm with the following command:
JB348-RHJBEAP7-en-6-20170411 89
[student@workstation ~]$ echo -n JBoss@RedHat123 | openssl base64
6. Start the host controller on servera with the configuration file /opt/domain/
configuration/host-slave.xml and point to the domain controller running on
172.25.250.254.
7. Create a new host controller with the following characteristics using the /home/student/
JB348/labs/configure-cluster/create-hc.sh script file:
• The base directory on serverb is /opt/domain and should set the owner as jboss.
• Set the name of the host to serverb.
• Use IP address of serverb (172.25.250.11) for the management, public, and private
interface.
8. Start the host controller on serverb with the configuration file /opt/domain/
172.25.250.254.
9. Stop and remove all of the servers (server-one, server-two) using the /home/
student/JB348/labs/configure-cluster/delete-server.sh script. In the next
steps, you will create new servers to deploy applications on these hosts.
9.1. Stop and remove the server-one server from servera host.
9.2. Stop and remove the server-two server from servera host.
9.3. Stop and remove the server-one server from serverb host.
9.4. Stop and remove the server-two server from serverb host.
10. Remove the server-groups (main-server-group, other-server-group) using the /

home/student/JB348/labs/configure-cluster/delete-server-group.sh script.
11. The cluster must define a new TCP stack configuration. The communication between the
nodes uses unicast. For this environment, unicast is a requirement, since it is more reliable.
Edit the file /tmp/new-tcp-stack.cli on the workstation VM and configure the
cluster to use TCP.
12. The cluster provides the messaging subsystem and HA capabilities from EAP, and these
features are available only in the full-ha profile. Create a new server group using the /
home/student/JB348/labs/configure-cluster/create-server-group.sh script
called Group1 which is used to emulate a development environment with the following
characteristics:
90 JB348-RHJBEAP7-en-6-20170411
• Name: Group1
• Profile: full-ha
• Socket Binding Group: full-ha-sockets
13. Create another server group called Group2 to use for deploying bookstore in a production
environment with the same characteristics as the development environment:
• Name: Group2
14. You need to define four servers (two each on servera and serverb). Create the servers
and assign them to the appropriate groups. Make sure that when you run multiple servers
on a host, you configure the port offsets correctly to avoid port clashes. Also ensure that
the servers are set to automatically start when the host controller is started or restarted.
To create the servers, use the /home/student/JB348/labs/configure-cluster/
create-server.sh script.
14.1. Create and start a new server called servera.1 on servera with the following
characteristics:
• Name: servera.1
• Server Group: Group1
• Socket Binding Port Offset: Leave at default value of 0
• Auto Start: true
14.2.Create and start a new server called servera.2 on servera with the following
characteristics:
• Name: servera.2
• Socket Binding Port Offset: 100
14.3.Create and start a new server called serverb.1 on serverb with the following
characteristics:
• Name: serverb.1
JB348-RHJBEAP7-en-6-20170411 91
characteristics:
• Name: serverb.2
15. You have now created four servers and associated them with the appropriate server groups.
Because a firewall is running on servera and serverb, you must unlock all ports used
by servera.1, servera.2, serverb.1, and serverb.2 for public access. Unlock the
following ports on servera and serverb using the /home/student/JB348/labs/
configure-cluster/firewall.sh script:
• 8080/tcp
• 8180/tcp
• 8009/tcp
• 8109/tcp
• 7600/tcp
• 7700/tcp
• 57600/tcp
• 57700/tcp
16. To get started creating the load balancer, copy files from JBOSS_HOME/standalone into
the lab directory at /opt/lb on the workstation. Set the owner of the /opt/lb directory to
user jboss.
17. Start the load balancer on workstation with the standalone-ha.xml and a port offset
of 1000 to avoid port clashes with the domain controller running on the workstation.
Because the load balancer is going to be the entry point for the application, it must be
configured to listen on the public IP of the workstation (172.25.250.254). Remember to
unlock the 9080/tcp port on the firewall.
18. Configure the load balancer for balancing requests using the modcluster. Set the password
for the advertise-security-key to redhat.
19. Configure the modcluster subsystem from the full-ha profile to enable the load
balancer. You must disable the advertise option and also configure the proxies list pointing
to the load balancer address (172.25.250.254:9080).
20. You are now ready to deploy the cluster application WAR file in the managed domain.
The cluster.war file is available in the /home/student/JB348/apps folder on the
workstation.
92 JB348-RHJBEAP7-en-6-20170411
20.1.Application deployments in a managed domain are always done at the server groups
level. Each application belongs to one or more server groups. Deploy the cluster.war
file to Group1.
Verify that the cluster.war file is deployed on servera.1 and serverb.1 because
they are part of the Group1 server group. Monitor the console window of servera and
serverb for any error messages or warnings.
20.2.Verify that you can access the cluster application at http://172.25.250.10:8080/

cluster and http://172.25.250.11:8080/cluster.
20.3.Verify that you can NOT access the cluster application at

http://172.25.250.10:8180/cluster or http://172.25.250.11:8180/
cluster because these servers are part of Group2 and you have not deployed the
application on Group2.
20.4.Verify that you can access the cluster application at

http://172.25.250.254:9080/cluster. This access are being handled by the load
balancer.

21.2.Run the following command from the workstation to grade the exercise:
[student@workstation ~]$ lab configure-cluster grade
JB348-RHJBEAP7-en-6-20170411 93
Solution
In this lab, you will create a managed domain and a load balancer.
Resources
Files: /home/student/JB348/labs/create-cluster, /home/
version
Outcomes
You should be able to start a domain controller and a load balancer on the workstation VM
and run a host controller on both server A and server B. The final solution should be in line
with the following architecture with regards to the host controller and the domain controller.
Before you begin

and to download the required files for this exercise:
[student@workstation ~]$ lab configure-cluster setup
94 JB348-RHJBEAP7-en-6-20170411
Solution
1. To get started creating the domain controller, copy files from JBOSS_HOME/domain into
the lab directory at /opt/domain on the workstation. Set the owner of the /opt/domain
directory to user jboss.
1.1. Run the following command to copy the EAP domain configuration to the /opt/domain
directory on the workstation.
[student@workstation ~]$ sudo cp -r /opt/jboss-eap-7.0/domain /opt/
1.2. Use the following command to set the directory owner as user jboss:
[student@workstation ~]$ sudo chown -R jboss:jboss /opt/domain
2. The EAP instance on workstation is the domain controller, and exposes the management
interface to an internal network. The network where all servers are connected to is the
172.25.250.X network. Other network interfaces should not be exposed to guarantee that
external host controllers may not get sensitive information from the domain controller.
Update the address of the management interface for the domain controller to point to the
workstation's IP address (172.25.250.254) using the host-master.xml configuration
file. Remember to unlock the 9990/tcp and 9999/tcp ports to allow the communication
between the domain controller and the host controllers:
2.1. Open the file /opt/domain/configuration/host-master.xml with a text editor

as user jboss.
2.2. Modify the interface sections of the configuration file as follows:
<interfaces>
</interface>
</interfaces>
2.3. Save your changes and exit the editor.
2.4. To unlock the firewall ports on workstation, run the following commands in a terminal
window:
[student@workstation ~]$ cd /home/student/JB348/labs/configure-cluster

[student@workstation configure-cluster]$ ./firewall.sh workstation 9990/tcp \
9999/tcp
3. Because the domain controller will run an application with high availability features,
including the messaging subsystem, some extra requirements are needed. The domain
controller is responsible for providing security information to allow server instances to be
part of a clustered environment, for all subsystems.
The messaging subsystem requires authentication to exchange data among cluster

members, and the credentials are declared in the domain.xml file. The details about the
subsystem are explained later, but for the environment to function correctly, the cluster
password must be declared at the domain controller configuration file.
JB348-RHJBEAP7-en-6-20170411 95
Update domain.xml on workstation to set the cluster password to JBoss@RedHat123.
3.1. As the jboss user, open the /opt/domain/configuration/domain.xml file on

workstation .
[student@workstation ~]$ sudo -u jboss vi /opt/domain/configuration/domain.xml
<cluster> tag (line 1278).
<cluster password="${jboss.messaging.cluster.password:JBoss@RedHat123}" />
4. Start the domain controller on the workstation.
4.1. In your terminal window, change directories to /opt/jboss-eap-7.0/bin:
[student@workstation domain]$ cd /opt/jboss-eap-7.0/bin
4.2. To start the domain controller using the host-master.xml file in your /opt/
domain/ folder.
Enter the following command:
[student@workstation ~]$ sudo -u jboss ./domain.sh \

-Djboss.domain.base.dir=/opt/domain/ \
Look for the following output to confirm that the domain controller is running:
[Host Controller] 01:50:11,359 INFO [org.jboss.as] (Controller Boot Thread)

WFLYSRV0060: Http management interface listening on http://172.25.250.254:9990/
management
WFLYSRV0051: Admin console listening on http://172.25.250.254:9990
5. An instance of EAP is already installed on both server A and server B. Create a new host
controller with the following characteristics using the /home/student/JB348/labs/
configure-cluster/create-hc.sh script file:
• The base directory on server A is /opt/domain and sets the owner as jboss.
• Set the name of the host to servera.
• Use the IP address of Server A, 172.25.250.10, for the management, public, and private
interface.
96 JB348-RHJBEAP7-en-6-20170411
Solution
Use the following commands on workstation to create the new host controller:

[student@workstation configure-cluster]$ ./create-hc.sh 172.25.250.10 /opt/domain \
servera jboss 172.25.250.10 172.25.250.10 172.25.250.10 jbossadm \
SkJvc3NAUmVkSGF0MTIz
6. Start the host controller on servera with the configuration file /opt/domain/
172.25.250.254.
6.2. Run the following command to start the host controller and connect to the domain
controller:

[student@servera bin]$ sudo -u jboss ./domain.sh \
--host-config=host-slave.xml \
-Djboss.domain.master.address=172.25.250.254 \
-Djboss.node.name=servera
6.3. Look in the terminal window of the host controller on servera. Carefully review the
log output and you should see the host controller connecting to the master, and also
server-one and server-two starting up.

remote://172.25.250.254:9999
6.4. Look in the terminal window of the domain controller running on the workstation. You
should see a log entry showing the slave connecting:

"servera", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)
7. Create a new host controller with the following characteristics using the /home/student/
JB348/labs/configure-cluster/create-hc.sh script file:
• The base directory on serverb is /opt/domain and should set the owner as jboss.
• Set the name of the host to serverb.
JB348-RHJBEAP7-en-6-20170411 97
• Use IP address of serverb (172.25.250.11) for the management, public, and private
interface.
Use the following commands on workstation to create the new host controller:

[student@workstation configure-cluster]$ ./create-hc.sh 172.25.250.11 /opt/domain \
serverb jboss 172.25.250.11 172.25.250.11 172.25.250.11 jbossadm \
SkJvc3NAUmVkSGF0MTIz
8. Start the host controller on serverb with the configuration file /opt/domain/
172.25.250.254.
[student@workstation configure-cluster]$ ssh serverb
8.2. Run the following command to start the host controller and connect to the domain
controller:

[student@serverb bin]$ sudo -u jboss ./domain.sh \
-Djboss.node.name=serverb
8.3. Look in the terminal window of the host controller of serverb. Carefully review the log
output and you should see the host controller connecting to the master.

remote://172.25.250.254:9999
8.4. Look in the terminal window of the domain controller running on workstation. You
should see a log entry showing the slave connecting:

"serverb", JBoss JBoss EAP 7.0.0.GA (WildFly 2.1.2.Final-redhat-1)
9. Stop and remove all of the servers (server-one, server-two) using the /home/
student/JB348/labs/configure-cluster/delete-server.sh script. In the next
steps, you will create new servers to deploy applications on these hosts.
98 JB348-RHJBEAP7-en-6-20170411
Solution
9.1. Stop and remove the server-one server from servera host.
[student@workstation bin]$ cd /home/student/JB348/labs/configure-cluster

[student@workstation configure-cluster]$ ./delete-server.sh servera server-one
9.2. Stop and remove the server-two server from servera host.
[student@workstation configure-cluster]$ ./delete-server.sh servera server-two
9.3. Stop and remove the server-one server from serverb host.
[student@workstation configure-cluster]$ ./delete-server.sh serverb server-one
9.4. Stop and remove the server-two server from serverb host.
[student@workstation configure-cluster]$ ./delete-server.sh serverb server-two
10. Remove the server-groups (main-server-group, other-server-group) using the /

home/student/JB348/labs/configure-cluster/delete-server-group.sh script.
10.1. Run the following command to remove main-server-group on workstation:
[student@workstation configure-cluster]$ ./delete-server-group.sh \

main-server-group
10.2.Run the following command to remove other-server-group on workstation:
[student@workstation configure-cluster]$ ./delete-server-group.sh \

other-server-group
11. The cluster must define a new TCP stack configuration. The communication between the
nodes uses unicast. For this environment, unicast is a requirement, since it is more reliable.
Edit the file /tmp/new-tcp-stack.cli on the workstation VM and configure the
cluster to use TCP.
11.1. Edit the initial_hosts property and replace the values with the host name and ports
of the two EAP server instances that should be part of the cluster.
..."initial_hosts":add(value="servera[7600],servera[7700],serverb[7600],
serverb[7700]")
Note
The 7600 port is used by JGroups to allow the communication between nodes.
11.2. Execute the EAP CLI script file on the domain controller.
JB348-RHJBEAP7-en-6-20170411 99

[student@workstation bin]$ sudo -u jboss ./jboss-cli.sh --connect \
--controller=172.25.250.254:9990 --file=/tmp/new-tcp-stack.cli
12. The cluster provides the messaging subsystem and HA capabilities from EAP, and these
features are available only in the full-ha profile. Create a new server group using the /
home/student/JB348/labs/configure-cluster/create-server-group.sh script
called Group1 which is used to emulate a development environment with the following
characteristics:
• Name: Group1
[student@workstation ~]$ cd /home/student/JB348/labs/configure-cluster/

[student@workstation configure-cluster]$ ./create-server-group.sh Group1 \
full-ha full-ha-sockets
13. Create another server group called Group2 to use for deploying bookstore in a production
environment with the same characteristics as the development environment:
• Name: Group2
[student@workstation configure-cluster]$ ./create-server-group.sh Group2 \

full-ha full-ha-sockets
14. You need to define four servers (two each on servera and serverb). Create the servers
and assign them to the appropriate groups. Make sure that when you run multiple servers
on a host, you configure the port offsets correctly to avoid port clashes. Also ensure that
the servers are set to automatically start when the host controller is started or restarted.
To create the servers, use the /home/student/JB348/labs/configure-cluster/
create-server.sh script.
14.1. Create and start a new server called servera.1 on servera with the following
characteristics:
• Name: servera.1
[student@workstation configure-cluster]$ ./create-server.sh servera \

servera.1 Group1 0 true
100 JB348-RHJBEAP7-en-6-20170411
Solution
14.2.Create and start a new server called servera.2 on servera with the following
characteristics:
• Name: servera.2
[student@workstation configure-cluster]$ ./create-server.sh servera \

servera.2 Group2 100 true
characteristics:
• Name: serverb.1
[student@workstation configure-cluster]$ ./create-server.sh serverb \

serverb.1 Group1 0 true
characteristics:
• Name: serverb.2
[student@workstation configure-cluster]$ ./create-server.sh serverb \

serverb.2 Group2 100 true
15. You have now created four servers and associated them with the appropriate server groups.
Because a firewall is running on servera and serverb, you must unlock all ports used
by servera.1, servera.2, serverb.1, and serverb.2 for public access. Unlock the
following ports on servera and serverb using the /home/student/JB348/labs/
configure-cluster/firewall.sh script:
• 8080/tcp
• 8180/tcp
• 8009/tcp
JB348-RHJBEAP7-en-6-20170411 101
• 8109/tcp
• 7600/tcp
• 7700/tcp
• 57600/tcp
• 57700/tcp
15.1. Unlock the ports on servera:
[student@workstation configure-cluster]$ ./firewall.sh servera 8080/tcp \

8180/tcp 8009/tcp 8109/tcp 7600/tcp 7700/tcp 57600/tcp 57700/tcp
15.2.Unlock the ports on serverb
[student@workstation configure-cluster]$ ./firewall.sh serverb 8080/tcp \

8180/tcp 8009/tcp 8109/tcp 7600/tcp 7700/tcp 57600/tcp 57700/tcp
15.3.Verify that you can access the default welcome page of all four servers you created
in the above steps. Access the following URLs and verify that you can see the EAP 7
Welcome page:
• servera.1: http://172.25.250.10:8080
• servera.2: http://172.25.250.10:8180
• serverb.1: http://172.25.250.11:8080
• serverb.2: http://172.25.250.11:8180
16. To get started creating the load balancer, copy files from JBOSS_HOME/standalone into
the lab directory at /opt/lb on the workstation. Set the owner of the /opt/lb directory to
user jboss.
16.1. Run the following command to copy the EAP domain configuration to the /opt/lb
directory on the workstation.
[student@workstation ~]$ sudo cp -r /opt/jboss-eap-7.0/standalone /opt/lb
16.2.Use the following command to set the directory owner as user jboss:
[student@workstation ~]$ sudo chown -R jboss:jboss /opt/lb
17. Start the load balancer on workstation with the standalone-ha.xml and a port offset
of 1000 to avoid port clashes with the domain controller running on the workstation.
Because the load balancer is going to be the entry point for the application, it must be
configured to listen on the public IP of the workstation (172.25.250.254). Remember to
unlock the 9080/tcp port on the firewall.
102 JB348-RHJBEAP7-en-6-20170411
Solution
17.1. To unlock the firewall port on workstation, run the following commands in a new
terminal window from workstation:

[student@workstation configure-cluster]$ ./firewall.sh workstation 9080/tcp
17.2. Run the following command to start the load balancer:
[student@workstation configure-cluster]$ cd /opt/jboss-eap-7.0/bin

-Djboss.server.base.dir=/opt/lb -Djboss.bind.address=172.25.250.254 \
-Djboss.socket.binding.port-offset=1000 -c standalone-ha.xml
18. Configure the load balancer for balancing requests using the modcluster. Set the password
for the advertise-security-key to redhat.
18.1. Launch the EAP CLI in a new terminal window and connect to the load balancer instance
on workstation.
In a new terminal window on the workstation, start the EAP CLI and connect to the
load balancer:

[student@workstation bin]$ ./jboss-cli.sh --connect --controller=localhost:10990
18.2.Configure the modcluster subsystem to act as a front-end load balancer. Set the
password for the advertise-security-key to redhat.
[standalone@localhost:10990 /] /subsystem=modcluster/mod-cluster-config=\
configuration:write-attribute\
(name=advertise-security-key, value=redhat)
18.3.Configure the mod_cluster filter. Advertise the load balancer using the modcluster
socket-binding and use the HTTP protocol for the management socket binding. Ensure
that the security-key attribute matches the advertise-security-key you
configured in the previous step.
[standalone@localhost:10990 /] /subsystem=undertow/configuration=\
filter/mod-cluster=modcluster:add\
(management-socket-binding=http, advertise-socket-binding=modcluster,\
security-key=redhat)
18.4.As a final step, bind the modcluster filter to the undertow default-server.
[standalone@localhost:10990 /] /subsystem=undertow/server=\
default-server/host=default-host/filter-ref=modcluster:add
18.5.Reload the load balancer configuration and exit from CLI:
[standalone@localhost:10990 /] :reload
JB348-RHJBEAP7-en-6-20170411 103
[standalone@localhost:10990 /] exit
19. Configure the modcluster subsystem from the full-ha profile to enable the load
balancer. You must disable the advertise option and also configure the proxies list pointing
to the load balancer address (172.25.250.254:9080).
19.1. In a new terminal window on the workstation, start the EAP CLI and connect to the
domain controller:

19.2.Configure the mod_cluster subsystem. By default, EAP is set up for advertising

its status to load balancers using UDP multicasting. Disable advertising in the
mod_cluster subsystem for the full-ha profile.
[domain@172.25.250.254:9990 /] /profile=full-ha/subsystem=modcluster\
/mod-cluster-config=configuration/\
:write-attribute(name=advertise,value=false)
19.3.Because you have disabled advertising, you need to configure the back-end EAP
nodes with a list of proxies (load balancers). Configure the EAP back-end nodes to
communicate with the load balancer running on the workstation VM. Ensure you
add an outbound socket binding that points to the load balancer IP address and port
(172.25.250.254:9080).
[domain@172.25.250.254:9990 /] /socket-binding-group=full-ha-sockets\
/remote-destination-outbound-socket-binding=lb:\
add(host=172.25.250.254,port=9080)
19.4.Next, add the proxies to the mod_cluster configuration:
[domain@172.25.250.254:9990 /] /profile=full-ha/subsystem=modcluster\
/mod-cluster-config=configuration:list-add(name=proxies,value=lb)
19.5.Reload the hosts:
[domain@172.25.250.254:9990 /] reload --host=servera

[domain@172.25.250.254:9990 /] reload --host=serverb
20. You are now ready to deploy the cluster application WAR file in the managed domain.
The cluster.war file is available in the /home/student/JB348/apps folder on the
workstation.
20.1.Application deployments in a managed domain are always done at the server groups
level. Each application belongs to one or more server groups. Deploy the cluster.war
file to Group1.
[domain@172.25.250.254:9990 /] deploy \
/tmp/cluster.war --server-groups=Group1
104 JB348-RHJBEAP7-en-6-20170411
Solution
Verify that the cluster.war file is deployed on servera.1 and serverb.1 because
they are part of the Group1 server group. Monitor the console window of servera and
serverb for any error messages or warnings.
20.2.Verify that you can access the cluster application at http://172.25.250.10:8080/

cluster and http://172.25.250.11:8080/cluster.
20.3.Verify that you can NOT access the cluster application at

http://172.25.250.10:8180/cluster or http://172.25.250.11:8180/
cluster because these servers are part of Group2 and you have not deployed the
application on Group2.
20.4.Verify that you can access the cluster application at

http://172.25.250.254:9080/cluster. This access are being handled by the load
balancer.

21.2.Run the following command from the workstation to grade the exercise:
[student@workstation ~]$ lab configure-cluster grade
JB348-RHJBEAP7-en-6-20170411 105
Summary
• A cluster should provide the following capabilities:
◦ High Availability (HA)
◦ Scalability
◦ Failover
◦ Fault Tolerance
◦ Load Balancing
• The Infinispan subsystem provides caching support for JBoss EAP, facilitating the high
availability features of clustered servers.
• There are four different types of caches on Infinispan:
◦ Local
◦ Invalidation
◦ Replication
◦ Distribution
• The JGroups Subsystem provides all the communication mechanisms for how the servers in a
cluster communicate with each other.
• JGroups consists of three parts:
◦ Channel
◦ Building blocks
◦ Protocol stack
• EAP 7 is preconfigured with two JGroups stacks:
◦ UDP
◦ TCP
• The singleton subsystem can be configured with different election policies that define the
master. Two kinds of election policies are provided by EAP 7:
◦ Simple
◦ Random
106 JB348-RHJBEAP7-en-6-20170411
TRAINING
CHAPTER 4
DEPLOYING APPLICATIONS
Overview
Goal Given a properly installed JBoss EAP and an application
archive, deploy an application in various types of production
environments.
Objectives • Enhance EAP with optional downloads.
• Describe how to deploy an application without any

downtime.
• Describe the process for deploying applications in the

cloud.
Sections • Installing EAP with Advanced Options (and Quiz)
• Understanding Rolling Upgrades (and Guided Exercise)
• Deploying Applications in the Cloud (and Quiz)

Lab • Deploying Applications
JB348-RHJBEAP7-en-6-20170411 107
Chapter 4. Deploying Applications
Installing EAP with Advanced Options
Objectives
After completing this section, students should be able to:
• Enhance EAP with optional downloads.
• Install EAP as a system service.
Optional downloads
There are several optional portions of EAP that can be installed locally to provide additional
services or additional information for developers using EAP. Many administrators may find the
need to extend the capabilities of the default installation in order to serve their organization's
needs or to integrate with previously existing systems. This section covers a brief survey of
these options. The following optional add-ons below are available for download from the Red Hat
Customer Portal.
Apache HTTP Server

The native Apache HTTP Server installation available on the Customer Portal is a simple way of
getting a supported version of Apache HTTP Server for the desired operating system.
Native Components
The native components download contains supporting libraries for use with EAP 7 and Apache
HTTP server. For the most part, these are the SSL modules and dll libraries.
Native Utilities
The native utilities package has various precompiled utilities for specific operating systems.
For the Solaris operating system, the following applications and libraries are available:
• Applications
◦ openssl
◦ jsvc
• Libraries
◦ libcrypto
◦ libssl
◦ libldap
◦ libsasl
◦ liblber
For the Windows operating system, the following applications are available:
• openssl
• prunmgr
• prunsvr
108 JB348-RHJBEAP7-en-6-20170411
Native Utilities
For the RHEL operating system, the following application is available:
• jsvc
Insight
jsvc is a tool to allow Java applications to run some privileged operations and then
revert to a non-privileged user. For example, this would allow EAP to bind to port
80 as root. For more information, see http://commons.apache.org/daemon/
jsvc.html
Webserver Connector Natives

The Webserver Connector Natives are used to connect a preinstalled web server to JBoss EAP
7. It's essentially a precompiled version of mod_cluster, which is the current best practice for
connecting Apache HTTP Server to JBoss EAP 7. In general, it is recommended to use these with
either the above server, or the JBoss Enterprise Web Server (another available download from
Customer Portal). These components are used to connect an HTTP server to JBoss EAP 7 for
clustering and failover. This download is used to install the natives on an Apache HTTP Server
which should never have JBoss EAP 7 installed on it as well.
Insight
These components can also be found under the modules/native install directory, if the
option is selected to include these in the basic EAP install.
Javadocs
Javadocs are primarily tools for developers. They allow developers to see the programming
interfaces used by various services within EAP 7 that developers can utilize to create robust
applications.
Maven Repository
The Maven repository for JBoss EAP 7 allows developers to use libraries provided by EAP 7
without having to copy JAR files across systems. It is a powerful tool for developers, and should
be encouraged by administrators to help simplify deployments and ensure compatibility of
applications across servers.
Quickstarts
Another useful tool for developers, the Quickstarts demonstrate how applications can be built
and deployed easily. Example applications run from very simple hello-world type applications
all the way up to more robust Java enterprise applications including a code-complete booking
application using CDI, EJBs, JPA, JSF, and so on.
Insight
While installation of the Quickstarts can be done during the install, they require the
Maven repository to be effective. Installation of the Quickstarts to a production system
is not recommended.
JB348-RHJBEAP7-en-6-20170411 109
JBoss EAP as a System Service

JBoss EAP can run as a service on all supported operating systems. The following demonstration
shows how to run EAP as a service on RHEL.
Demonstration: Running EAP as a Service on RHEL

1. Navigate to the /opt/jboss-eap-7.0/bin/init.d/jboss-eap.conf file and open it
in a text editor as the jboss user.
2. In the jboss-eap.conf file, edit the JBOSS_HOME variable to "/opt/jboss-eap-7.0"

and the JBOSS_USER to jboss. Uncomment both of the variables. The values must look like
the following:
...
## Location of JBoss EAP
JBOSS_HOME="/opt/jboss-eap-7.0"
## The username who should own the process

JBOSS_USER=jboss
3. Notice the other options available. Use these options if a configuration file other than
standalone.xml is desired. In this instance, leave the other options commented out and
use the default standalone.xml as well as the JBOSS_MODE to standalone . Save the file.
4. Copy the modified service configuration file to the /etc/default directory.
[student@workstation ~]$ sudo cp /opt/jboss-eap-7.0/bin/init.d/jboss-eap.conf \

/etc/default
5. Copy the EAP RHEL script to the /etc/init.d/ directory.
[student@workstation ~]$ sudo cp /opt/jboss-eap-7.0/bin/init.d/jboss-eap-rhel.sh \

/etc/init.d
6. Create the jboss-eap-rhel.service file in the /etc/systemd/system directory.
[student@workstation ~]$ sudo vi /etc/systemd/system/jboss-eap-rhel.service
7. Add the following to the jboss-eap-rhel.service file:
[Unit]
Description=JBoss EAP Systemctl script
After=NetworkManager.service
[Service]
Type=forking
ExecStart=/etc/init.d/jboss-eap-rhel.sh start
ExecStop=/opt/server/jboss-eap-6/bin/init.d/jboss-eap-rhel.sh stop
ExecReload=/opt/server/jboss-eap-6/bin/init.d/jboss-eap-rhel.sh restart
[Install]
WantedBy=multi-user.target
110 JB348-RHJBEAP7-en-6-20170411
Demonstration: Running EAP as a Service on RHEL
Save and close the file.
8. Reload the systemd daemon:
[student@workstation ~]$ sudo systemctl daemon-reload
9. Start the service using the following command:
[student@workstation ~]$ sudo systemctl start jboss-eap-rhel
10. Verify that EAP is running by visiting http://localhost:8080. Also run the following
command to see the service running:
[student@workstation ~]$ sudo systemctl status jboss-eap-rhel
11. Stop the EAP service:
[student@workstation ~]$ sudo systemctl stop jboss-eap-rhel
JB348-RHJBEAP7-en-6-20170411 111
Quiz: Running EAP as a Service on RHEL
Match the items below to put the steps for running EAP as a service on RHEL in order. The order
is based on the order the steps are executed in the demonstration from the previous section.
1 2 3 4 5 6
Action Order
Copy the jboss-

eap.conf file to
the /etc/default
directory
Reload the systemd

daemon
Create the jboss-

eap-rhel.service
file
Use systemctl to
start the service
Update the jboss-

eap.conf file
Copy the jboss-eap-

rhel.sh script to /
etc/init.d
112 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
Match the items below to put the steps for running EAP as a service on RHEL in order. The order
is based on the order the steps are executed in the demonstration from the previous section.
Action Order
Copy the jboss- 2

eap.conf file to
the /etc/default
directory
Reload the systemd 5

daemon
Create the jboss- 4

eap-rhel.service
file
Use systemctl to 6
start the service
Update the jboss- 1

eap.conf file
Copy the jboss-eap- 3

rhel.sh script to /
etc/init.d
JB348-RHJBEAP7-en-6-20170411 113
Understanding Rolling Upgrades
Objectives
• Describe the deployment process in EAP 7.
• Describe how to use the JBoss Maven Plugin.
• Describe how to deploy an application without any downtime.
Deployment Process Review

From previous versions of EAP, and in previous units of this course, users should be familiar with
a variety of methods for deploying applications. Here's a brief review:
• In EAP 6 and earlier, as well as with EAP 7 standalone servers, users can place a file in a
configurable directory ($JBOSS_HOME/standalone/deployments by default), and the
server deploys it.
◦ Applications may be hot deployed while the server is running, or delayed until a server
restart.
◦ EAP 7 also allows users to add named files to control deployments, such as
app.war.dodeploy and app.war.ignore.
• With a managed domain in EAP 7, applications can be deployed to a server group using the
management console, or the CLI.
• When using Maven, the JBoss libraries include the ability to deploy and undeploy applications
to standalone servers using the wildfly-maven plugin, configured in the application's
pom.xml. The wildfly:deploy and wildfly:undeploy directives handle the actual
deployment.
Deploying with the JBoss Maven Plugin

Building an application and then manually deploying it can become a needlessly tedious task.
Administrators may be interested in using Maven to deploy an application to a server. In many
cases, this could be used as part of a continuous integration initiative. To deploy with Maven,
ensure that the JBOSS_HOME environment variable is set to the location of the desired EAP
instance. Then update the application pom.xml file to include the following plugin:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.1.0.Final</version>
</plugin>
Deploy an application with the following command:
mvn wildfly:deploy
To undeploy, run the following command:
114 JB348-RHJBEAP7-en-6-20170411
Rolling Upgrades
mvn wildfly:undeploy
Rolling Upgrades
A basic rolling upgrade scheme is designed to allow administrators to upgrade applications
without any downtime. There are cases where this is not important, such as:
• An internal, company-only application, or any application with no guaranteed uptime.
• An application upgrade with major changes that are incompatible with the previous version.
• An application upgrade with significant security implications where the previous version, if
used, is poses a security threat.
For most client-facing web applications today, however, a rolling upgrade is a key method for
ensuring that customers won't face downtime.
Steps to Create Rolling Upgrades

For the most part, the process for a rolling upgrade is just that: a process. However, it does
require an architecture that can support the process. There are many ways to set up such an
architecture, but for this section, we will use the following:
Figure 4.1:
Figure 1-1. An example architecture that can support rolling upgrades.
In Figure 1-1 there are two three-node clusters, running the same application, and sharing the
same server profile, in Cluster A and Cluster B. Both clusters report to the same mod_cluster
load balancer, though they use separate load balancer group names, to ensure that a session
from Cluster A doesn't accidentally try to fail over to Cluster B. The steps to perform a rolling
upgrade on this architecture are as follows:
1. Suspend the nodes from Cluster A in the load balancer, causing the servers to finish any
outstanding transactions and to reject new connections.
2. Apply updates to Cluster A from the domain controller.

• For application upgrades, this is generally a simple process, as binary compatibility is less
of a concern when all nodes in a cluster are upgraded at once.
JB348-RHJBEAP7-en-6-20170411 115
• Be aware of any changes to the database, as that is often shared across cluster
boundaries. As a solution, a secondary database used during the rolling update may
continue to be used until all nodes have been updated.
3. Start up Cluster A and test the changes.
4. Enable Cluster A's nodes in the load balancer.
5. Once Cluster A is taking some of the load properly, bring down Cluster B and repeat steps 1
through 4.
Insight
The Domain controller can be brought down at any time. Hosts that are already
running won't have any issues continuing to run, and will only present warnings about
the missing domain controller until it is brought back online. The only real issue is
trying to bring up new host controllers with servers in a server group managed by that
domain controller. They will not start up properly. But with a little forward planning, this
minor issue can be avoided easily.
Configurations for Rolling Upgradable EAP Clusters

To perform the steps above consistently, the cluster needs some important configurations for
optimal performance.
• Create a server group for each cluster in domain.xml, which use nearly identical setups:
<server-groups>
<server-group name="group-clusterA" profile="ha">
<jvm name="default">
<heap size="512m" max-size="512m"/>
<permgen max-size="256m"/>
</jvm>
<socket-binding-group ref="ha-sockets"/>
</server-group>
<server-group name="group-clusterB" profile="ha">
<jvm name="default">
<heap size="512m" max-size="512m"/>
<permgen max-size="256m"/>
</jvm>
<socket-binding-group ref="ha-sockets"/>
</server-group>
</server-groups>
• Set up load balancing groups for the profile which can be managed via system property:
<mod-cluster-config
advertise-socket="modcluster"
sticky-session-remove="true"
sticky-session-force="true"
load-balancing-group="${mysysprops.lbgroup:default}"
connector="ajp">
Administrators can set a stop-context-timeout attribute. This sets the number of seconds
to wait for a context to finish processing requests.
116 JB348-RHJBEAP7-en-6-20170411
Rollout Plans and Rollbacks
• Set up the servers to be in separate clusters and load balancing groups based on the above
settings:
<server name="serverA" group="group-clusterA">

<system-properties>
<property name="jboss.default.multicast.address" value="230.0.1.1"/>
<property name="mysysprops.lbgroup" value="clusterA"/>
</system-properties>
</server>
These system properties can also be set at the server-group level.
Rollout Plans and Rollbacks

A rollout plan allows an administrator to roll out an application or other configuration update to
groups and servers either serially or concurrently, and allows the administrator to set a threshold
for "successful" roll outs to a percentage of the servers, or setting a maximum number of failed
servers, before a rollback is enforced.
When rolling out configuration updates to servers without an explicit roll-out plan, the default
plan has the following characteristics:
• All selected server groups will be updated concurrently.
• All servers in the group get the update concurrently.
• Failure on any server in the group triggers a rollback for the entire group.
• If more than one server group is selected, failure on one server group triggers a rollback of all
server groups. If any server in any group fails, all servers in all groups will be rolled back.
JB348-RHJBEAP7-en-6-20170411 117
Guided Exercise: Performing a Rolling Update
In this exercise, you will perform a rolling update of an application in an EAP 7 cluster.
Resources
Files: /home/student/JB348/labs/deploy-rolling/
Application URL: http://172.25.250.254:9080/cluster
Outcomes
You will be able to perform a rolling update to an application.
Before you begin

Use the following command in the workstation VM to set up an EAP cluster with a load
balancer, open the firewall ports, and to download both cluster applications:
[student@workstation ~]$ lab deploy-rolling setup
1. Start the Managed Domain

The setup script for this guided exercise downloaded files for a preconfigured managed
domain. This is the same managed domain from the solution of the guided exercise
Troubleshooting JGroups in the previous chapter with an additional server group and
two more servers, one on each host. The domain includes a load balancer in front of two
host controllers with two server groups (cluster-group, and cluster-group2) for
four servers (cluster-one, cluster-two, cluster-three, cluster-four), with two
servers running on each host servera and serverb.
1.1. Open a new terminal window from workstation and run the following command to
start the load balancer:

-Djboss.server.base.dir=/home/student/JB348/labs/deploy-rolling/lb \
1.2. In a new terminal window on the workstation, run the following commands to start
the domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/deploy-rolling/machine1/ \
1.3. Open a terminal window from the workstation VM and access the servera VM using
the ssh command:
118 JB348-RHJBEAP7-en-6-20170411
the SSH command:

2. Deploy the Cluster Application

2.1. In a web browser on the workstation, navigate to 172.25.250.254:9990 to access
the management console. Use the following credentials to log in:
2.2. Click Deployments and then click Content Repository. Click Add in the second column.
2.3. Select Upload a new deployment and then click Next.
2.4. Browse to the cluster application /home/student/JB348/apps/cluster.war and

then click Next. In the next window click Finish.
2.5. Back in the content repository, click Assign next to cluster.war. Select both server
groups and select Enable assignment. Then click Assign.
2.6. Wait for a notification in the console to inform you that the application was deployed.
2.7. In a web browser on the workstation, navigate to http://172.25.250.254:9080/

cluster and the load balancer will serve the application to one of the four servers.
Take note of which server and which node is serving the request.
3. Upgrade Application
The cluster application is working really well, but a new and improved (and more colorful)
version is ready for release. Your managers want to ensure that the transition from the old
version of the app to the new one is seamless without any downtime for users. Disable one
of the server groups, verify that the old application is still up and running, and then deploy
the new app to the disabled server group. Repeat the process for the other group.
3.1. In the Management Console, click Runtime and then click Server Groups in the first
column. From there, click cluster-group.
3.2. Click the down arrow next to cluster-group and then click Suspend. This suspends the
server, which suspends server operations gracefully. All active requests are completed
JB348-RHJBEAP7-en-6-20170411 119
normally, but does not accept new requests. When prompted, leave the default value of
0 as the timeout for the server suspension.
3.3. Return to the application in the web browser. Observe that the server serving the
request may have changed as one server group is no longer accepting new requests.
Note
If you were originally being served a request from a server in cluster-
group2, then you will not see any difference as that is the only remaining
server group still serving the application.
3.4. Back in the management console, click Deployments, then click Server Groups and
finally click cluster-group.
3.5. Click cluster.war and then click the arrow next to the application and click Unassign to
remove the old cluster application.
3.6. In the same deployment column click Add and then select Upload a new deployment in
the window. Click Next.
3.7. Browse to the cluster application /home/student/JB348/apps/clusterv2.war

and then click Next. On the next window select Enable and then click Finish.
3.8. Click Runtime and select Resume next to the cluster-group server group.
3.9. Return to the application and refresh the page. Notice the application is still up and
running and half of the servers are serving the new application.
3.10.Return to the Management Console and suspend the cluster-group2 servers. Click
Deployments and unassign the cluster.war application to the cluster-group2 server
group.
3.11. After the cluster.war application is unassigned, click Add under Deployments and
then select Choose a deployment from the content repository and then click Next.
Select clusterv2.war and select Enable, then click Finish.
3.12. Click Runtime and select Resume next to the cluster-group2 server group.
3.13. Return to the web browser and refresh the page again. The application has now been
fully updated without any downtime for users. The new application features a new color
scheme.

migrated.
[student@workstation ~]$ lab deploy-rolling grade
4.2. Press Ctrl+C in the terminal windows where you started the instances of EAP 7 to stop
the servers.
120 JB348-RHJBEAP7-en-6-20170411
JB348-RHJBEAP7-en-6-20170411 121
Deploying Applications in the Cloud
Objectives
• Describe the process for deploying applications in the cloud.
• Describe monolithic architecture as it compares to microservices.
• Describe the concept of Platform as a Service (PaaS).
Using Lightweight Deployments

Traditional development of applications often has many distinct functions packaged as a single
deployment unit. This is known as a monolithic application. In addition, traditional development
may put supporting services such as databases and other middleware services on the same
server as the application or may have multiple applications running on the same server.
Having smaller deployments and breaking an application and its supporting services into multiple
deployments provides many advantages, such as:
• Higher hardware utilization, as smaller deployments are easier to fit into the host's available
space.
• Easier scaling, as parts of the application may be scaled to support an increased workload
without scaling other parts of the application.
• Easier upgrades, as parts of the application can be updated without interrupting service for
other parts of the same application that provides unrelated functions.
A microservices architecture is a model for designing software wherein the application is

comprised of several independent, small services that collaborate to deliver the business goals.
As an example, consider a simple Java application that allows users to manage a to-do list. A
traditional monolithic architecture could feature the front end and business logic all bundled
together as a single application. Using a microservices approach, the application can be split
into independent deployments for each tier, and then further broken down the service tier to
maximize reusability. For example, the front end and back ends of the application can each be
broken out into a separate server to allow scaling of individual tiers.
A service layer can bridge the front end to the back end in a flexible way. In this example, the
service layer could contain methods for accessing user credential information as well as user
data for the to-do list application. If the creators of the application wanted to create a brand new
application, but wanted to reuse the same user credentials, they could refactor the service layer
to isolate the user credential service. This process can repeat to create smaller services that can
be reused and can collaborate in order to achieve the business goals.
The Wildfly Swarm community project focuses on taking a Wildfly application server and
selectively stripping away parts of the server to create a self-contained, lightweight, uberjar.
The "uberjar" is ideal for these types of microservice architectures that need very minimal
application server support. In order to create a WildFly swarm deployment, add the following
plugin in the applications pom.xml:
<plugin>
122 JB348-RHJBEAP7-en-6-20170411
Identifying the Benefits of Containers
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>package</goal>
</goals>
</execution>
</executions>
</plugin>
Note
The Wildfly Swarm project does not yet have a Red Hat supported release.
After including the plugin, the application can be packaged with a normal mvn package, to
create a myapp-swarm.jar. Execute the application with mvn wildfly-swarm:run and the
application will run with a minimal Wildfly runtime. Alternatively, the generated uberjar can be
run with the following command:
java -jar <myapp>-swarm.jar
References
To learn more about Wildfly Swarm, visit http://wildfly-swarm.io.
In addition to Wildfly Swarm, MicroProfile is a baseline platform definition optimizing Enterprise

Java to facilitate a microservices architecture. By stripping away aspects of Java EE and
focusing on just JAX-RS, CDI, and JSON-P, as well as opening the door for an active community,
MicroProfile optimizes and innovates Enterprise Java for a microservices architecture.
References
To learn more about Microprofile, visit https://microprofile.io/.
Identifying the Benefits of Containers

Software applications are typically deployed as a single set of libraries and configuration files to
a runtime environment. They are traditionally deployed into an operating system with a set of
services running, such as a database server or an HTTP server, but they also may be deployed
on any environment that can provide the same services, such as a virtual machine or a physical
host.
The major drawback in this approach is that it is entangled with the runtime environment. Any
updates or patches applied to the base OS can break the application. If another application is
sharing the same host OS and the same set of libraries, as presented in the diagram, there is a
risk of breaking it if an update fixing the first application's libraries also affects the second app.
Thus, for a company developing typical software applications, any maintenance procedure to
the running environment may require a full set of tests to guarantee that any OS update do not
JB348-RHJBEAP7-en-6-20170411 123
affect the application as well. The maintenance may become cumbersome, and any deployment
or update becomes a complex process.
Figure 4.2: Container versus operating system differences
Alternatively, a system administrator may work with containers, which are a kind of isolated
partition inside a single operating system. Containers provide many of the same benefits as
virtual machines, such as security, storage, and network isolation, while requiring far fewer
hardware resources and being quicker to launch and terminate. It also isolates the libraries and
the runtime environment (such as CPU and storage usage) used by an application to minimize
impacts from any OS update from the host OS, as presented in the previous diagram.
Major advantages of containers include:
• Low hardware footprint: Uses OS internal features to create an isolated environment where
resources are managed using OS facilities such as namespaces and cgroups. This approach
minimizes the amount of CPU and memory overhead compared to a virtual machine
hypervisor.
• Environment isolation: Works in a closed environment where changes made to the host OS or
other applications do not affect the container. Since all the libraries needed by a container are
self-contained, the application is able to run without disruption. For instance, each application
lives in its own container with its own set of libraries. An update made to a container does not
affect other containers, which may not work with the update.
• Quick deployment: Deploys any container quickly since there is no need for a full OS install or
restart. Normally, to ensure isolation, a new OS would be installed on a physical host or VM
and any simple update may require a full OS restart. A container will require a simple restart
without stopping any services from the host OS.
• Multiple environment deployment: In a traditional deployment scenario using a single host,

any environment differences may potentially break the application, but using containers, the
differences and incompatibilities are mitigated because the same container image is used.
• Reusability: The same container may be reused by multiple applications without the need to set
up a full OS. A database container may be used to create a set of tables needed by a software
application, and it can be quickly destroyed and recreated without the need to run a set of
housekeeping tasks. Additionally, the same database container can be used by the production
environment to deploy an application.
Finally, containers boost the microservices development approach since they provide a
lightweight and reliable environment to create and run services that can be deployed on a
production or development environment without the complexity involved on a multiple machine
environment setup and management.
124 JB348-RHJBEAP7-en-6-20170411
Docker Core Elements
Docker is one of the container implementations available for deployment and supported by
companies such as Red Hat in their Red Hat Enterprise Linux Atomic Host platform. Docker Hub
provides a large set of containers developed by a vibrant developer community and it will be
used by this course to implement containerized services.
Docker Core Elements

Docker depends on three major elements:
• Images: These are read-only templates that contain a runtime environment including
application libraries and applications. Images are used to create containers. Images can be
created, updated, or downloaded for immediate consumption.
• Registries: These are responsible for storing images for public or private usage. The well-known
public registry is Docker Hub and it stores multiple images developed by the community, but
private registries may be created to support internal image development under a company's
discretion. This course runs on a private registry in a virtual machine where all the required
images are stored for faster consumption.
• Containers: Containers are segregated user space environment for running an application
isolated from other applications sharing the same host OS.
Containerizing with the OpenShift Container Platform

OpenShift Container Platform is Red Hat's Cloud Computing Platform as a Service (PaaS)
offering. OpenShift is an application platform in the cloud where application developers and
teams can develop, deploy, and manage container-based applications. OpenShift is designed to
enable users to create, modify, and deploy applications on demand.
OpenShift is a layered system that exposes underlying Docker-formatted container images

and uses the open source container management tool Kubernetes to orchestrate the container
cluster. Kubernetes performs several key functions, such as load balancing, high availability by
automatically detecting when a node fails, and scaling based on demand. These features are very
useful for facilitating the management of a container cluster. While Docker organizes single units
of work as containers, Kubernetes, and by extension OpenShift Container Platform, use pods. A
pod is a collection of containers that can share an IP address and volumes for storage.
JB348-RHJBEAP7-en-6-20170411 125
Figure 4.3: The OpenShift Container Platform groups containers together in pods.
After installing OpenShift Container Platform, users can take advantage of the Red Hat xPaaS
images that support Red Hat Middleware products, such as JBoss EAP to facilitate creation,
management and deployment of applications. xPaaS is a rich set of application development
and integration capabilities that enable users to build and deploy complex enterprise-scale
applications without spending as much time on infrastructure. The Red Hat xPaaS offering
includes the following images:
• Red Hat A-MQ
• Red Hat Data Grid
• Red Hat Decision Server (BRMS)
• Red Hat EAP
• Red Hat Fuse
• Red Hat Intelligent Process Server (BPM Suite)
• Red Hat Data Virtualization
• Red Hat SSO
• Red Hat JBoss Web Server
Using the xPaaS EAP image, developers and administrators can quickly build, scale, and test
applications. There are two major differences between the xPaaS EAP image and EAP. First, the
EAP Management Console is not included. This requires users to take advantage of the EAP CLI
for configuration instead. Second, the managed domain is not currently supported, however a
similar functionality is available through the OpenShift platform itself instead.
To use the xPaaS EAP image, run the following command using the oc OpenShift command-line
tool:
$ oc new-app <eap7-basic-s2i>
By passing in a link to a Java EE repository, OpenShift's source-to-image (S2I) feature

automatically pull an image based on the language type of the application in the repository.
S2I is an ideal feature for improving deployment speed and quick patch updates. For Java, a
preconfigured EAP image will deploy the application on an instance of JBoss EAP. If a pom.xml
file is present at the root of the repository, a maven build process is triggered. To use a custom
standalone.xml file, users can create a file called standalone-openshift.xml to override
the default standalone.xml in the running container. All files in the modules source repository
are copied into the EAP_HOME/modules directory in the container instance of EAP.
Similarly, OpenShift's S2I feature enables builds for the following languages in addition to Java:
• Node.js
• Ruby
• Perl
• PHP
126 JB348-RHJBEAP7-en-6-20170411
Containerizing with the OpenShift Container Platform
• Python
OpenShift provides a template to make creating a new database easier. The template provides
parameter fields for the required environment variables. When using the openshift process
command, or the OpenShift web console, to pass in the template and the required variables,
OpenShift creates the list of objects needed for the database. For example, the required variables
for the MySQL template are:
• MySQL user name
• MySQL password
• MySQL database
• MySQL root password
After instantiating the service from the template, administrators can copy the necessary
environment variables into a deployment configuration for another component that intends to
access the database, such as a JEE deployment. The JEE deployment can then access the MySQL
container via the service that is created.
A microservices architecture aims to have each service be independently deployable, scalable,

modular, compatible with the other service, and can be managed by other teams. OpenShift
Container Platform provides an ideal platform for microservices. An OpenShift cluster is a
flexible, scalable, and resource-efficient infrastructure that minimizes administrative effort. With
its ability to streamline developer workflows, as well as the automation technologies and stability
of its cloud architectures, the OpenShift Container Platform helps administrators manage and
coordinate microservices with ease.
JB348-RHJBEAP7-en-6-20170411 127
1. Which technology can be used to create a lightweight uberjar that is ideal for a
microservices architecture?
a. Microprofile
b. Wildfly Swarm
c. Docker
d. OpenShift Container Platform
e. Kubernetes
2. Which of the following describes a monolithic application?
a. A separate deployment for the user interface and the data access code.
b. A single-tiered application with a combined user interface and data access code.
c. A series of small services deployed as an "uberjar".
d. A containerized application that separates a REST API from a datasource.
3. Which of the following two statements about containers are true? (Choose two.)
a. Containers work in a closed environment, where changes to the host OS or other

applications won't affect the container.
b. Containers persist data by default.
c. Containers prioritize individual resiliency.
d. Containers can be used to monitor low-level systems on a host machine.
e. Containers prioritize being lightweight.
4. Which statement describes images in Docker?
a. A segregated user space for running an application.

b. Read-only templates that contain a runtime environment.
c. A collection of containers.
d. A configuration file for running containers to use.
e. None of the above.
5. Which technology does OpenShift Container Platform use for orchestrating containers?
a. Docker
b. Kubernetes
c. A-MQ
d. Jax-RS
128 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
1. Which technology can be used to create a lightweight uberjar that is ideal for a
microservices architecture?
a. Microprofile
b. Wildfly Swarm
c. Docker
d. OpenShift Container Platform
e. Kubernetes
2. Which of the following describes a monolithic application?
a. A separate deployment for the user interface and the data access code.
b. A single-tiered application with a combined user interface and data access code.
c. A series of small services deployed as an "uberjar".
d. A containerized application that separates a REST API from a datasource.
3. Which of the following two statements about containers are true? (Choose two.)
a. Containers work in a closed environment, where changes to the host OS or other

applications won't affect the container.
b. Containers persist data by default.
c. Containers prioritize individual resiliency.
d. Containers can be used to monitor low-level systems on a host machine.
e. Containers prioritize being lightweight.
4. Which statement describes images in Docker?
a. A segregated user space for running an application.

b. Read-only templates that contain a runtime environment.
c. A collection of containers.
d. A configuration file for running containers to use.
e. None of the above.
5. Which technology does OpenShift Container Platform use for orchestrating containers?
a. Docker
b. Kubernetes
c. A-MQ
d. Jax-RS
JB348-RHJBEAP7-en-6-20170411 129
Lab: Deploying Applications
In this lab, you will deploy a new, updated version of the cluster.war application and, without
causing any downtime for users, roll the application back to the previous version.
Resources
Files: /home/student/JB348/labs/deploying-lab,
Outcomes
You will be able to take advantage of a clustered domain to upgrade or downgrade applications
without any downtime.
Before you begin

Use the following command on the workstation to download the necessary applications and to
verify that the cluster is correctly configured:
[student@workstation ~]$ lab deploying-lab setup
Using the cluster created in the previous lab, you are going to roll back an application upgrade
that went badly. The cluster is organized as follows:
130 JB348-RHJBEAP7-en-6-20170411
1. Start the Load Balancer
Management has announced that the latest and greatest update to the Cluster application
is ready for release in production. The new green version of the app is expected to be
groundbreaking. First, start the load balancer as a standalone instance located on the
workstation. Use the following information for starting the load balancer:
• Base directory: /opt/lb
• Bind address: 172.25.250.254
• Configuration file: standalone-ha.xml

With the load balancer up and running, start the domain controller on the workstation
with the host-master.xml host configuration file and set the base directory as /opt/
domain.
Start the host controllers on servera and serverb using the host-slave.xml file and
connecting to the domain controller running on 172.25.250.254. Set the base directory for
each to /opt/domain and set the node name to be servera or serverb, depending on
where the host controller is being started.
3. Deploy the Updated Cluster Application

Use the management console to deploy the /home/student/JB348/apps/
clusterv3.war cluster application onto both server groups.
4. Verify that the New Application Works

Use a web browser to verify that the application works correctly by navigating to
http://172.25.250.254:9080/cluster.
5. Roll Back Group 1

Apparently some issues slipped by QA. Management wants you to roll back the application
as smoothly as possible without downtime. Use the managed domain to suspend the servers
in Group 1. Then verify that the application is still deployed. Then redeploy the /home/
student/JB348/apps/clusterv2.war application and re-enable the servers.

Using the same strategy, suspend the Group 2 servers, redeploy the clusterv2.war
application and then re-enable the servers.
7. Verify that the Application Works Again

Use a web browser to verify that the clusterv2 application is being served again and that
it functions properly by navigating to http://172.25.250.254:9080/cluster

[student@workstation ~]$ lab deploying-lab grade
8.2. Press Ctrl+C in the terminal window where you started the instances of EAP.
JB348-RHJBEAP7-en-6-20170411 131
132 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
In this lab, you will deploy a new, updated version of the cluster.war application and, without
causing any downtime for users, roll the application back to the previous version.
Resources
Files: /home/student/JB348/labs/deploying-lab,
Outcomes
You will be able to take advantage of a clustered domain to upgrade or downgrade applications
without any downtime.
Before you begin

Use the following command on the workstation to download the necessary applications and to
verify that the cluster is correctly configured:
[student@workstation ~]$ lab deploying-lab setup
Using the cluster created in the previous lab, you are going to roll back an application upgrade
that went badly. The cluster is organized as follows:
JB348-RHJBEAP7-en-6-20170411 133

Management has announced that the latest and greatest update to the Cluster application
is ready for release in production. The new green version of the app is expected to be
groundbreaking. First, start the load balancer as a standalone instance located on the
workstation. Use the following information for starting the load balancer:
• Bind address: 172.25.250.254


With the load balancer up and running, start the domain controller on the workstation
with the host-master.xml host configuration file and set the base directory as /opt/
domain.
each to /opt/domain and set the node name to be servera or serverb, depending on
On the workstation:
[student@workstation ~]$ cd /opt/jboss-eap-7.0/bin \

[student@workstation ~]$ sudo -u jboss ./domain.sh \
On servera:

On serverb:

134 JB348-RHJBEAP7-en-6-20170411
Solution
3. Deploy the Updated Cluster Application

Use the management console to deploy the /home/student/JB348/apps/
clusterv3.war cluster application onto both server groups.
3.1. In a web browser on the workstation, navigate to 172.25.250.254:9990 to access

the management console.
3.2. Click Deployments and then click Content Repository. Click Add in the second column.
Select Upload a new deployment and then click Next.

and then click Next. On the next window, click Finish.
3.4. Back in the content repository, click Assign next to cluster.war. Select both server
groups and select Enable assignment. Then click Assign
4. Verify that the New Application Works

Use a web browser to verify that the application works correctly by navigating to
http://172.25.250.254:9080/cluster.

Apparently some issues slipped by QA. Management wants you to roll back the application
as smoothly as possible without downtime. Use the managed domain to suspend the servers
in Group 1. Then verify that the application is still deployed. Then redeploy the /home/
student/JB348/apps/clusterv2.war application and re-enable the servers.
column. From there, click Group1.
5.2. Click the down arrow next to Group1 and then click Suspend. This will suspend the
server, which suspends server operations gracefully. All active requests will complete
normally, but it will not accept new requests. When prompted, leave the default value of
5.3. Click Deployments, then click Server Groups and finally click Group1.
5.4. Click clusterv3.war and then click the arrow next to the application and click Unassign
to remove the old cluster application.
5.5. In the same deployment column click Add and then select Upload a new deployment in
the window. Click Next.

and then click Next. On the next window select Enable and then click Finish.
5.7. Click Runtime and select Resume next to the Group1 server group.

Using the same strategy, suspend the Group 2 servers, redeploy the clusterv2.war
application and then re-enable the servers.
JB348-RHJBEAP7-en-6-20170411 135
column. From there, click Group2.
6.2. Click the down arrow next to Group2 and then click Suspend. This will suspend the
server, which suspends server operations gracefully. All active requests will complete
normally, but it will not accept new requests. When prompted, leave the default value of
6.3. Click Deployments, then click Server Groups and finally click Group2.
6.4. Click clusterv3.war and then click the arrow next to the application and click Unassign
to remove the old cluster application.
6.5. In the same deployment column, click Add and then select Choose a deployment from
the content repository in the window. Click Next.
6.6. Select the clusterv2.war application and select Enable and then click Finish.
6.7. Click Runtime and select Resume next to the Group2 server group.
7. Verify that the Application Works Again

Use a web browser to verify that the clusterv2 application is being served again and that
it functions properly by navigating to http://172.25.250.254:9080/cluster

[student@workstation ~]$ lab deploying-lab grade
136 JB348-RHJBEAP7-en-6-20170411
Summary
Summary
• JBoss EAP 7 installation includes the options to download Quickstarts as well as Javadocs that
are useful for getting started with EAP.
• Using a managed cluster, administrators can plan a rolling upgrade that prevents downtime
during application or server changes.
• The JBoss Maven plugin provides a simple way of deploying an application to EAP without
requiring an additional manual step after building the application.
• A roll out plan allows administrators to set thresholds and define a successful roll out,
preventing server failures from compromising a server update.
• A microservices architecture is a model for designing software wherein the application is

comprised of several independent and small services that collaborate to deliver business goals.
• WildFly Swarm is a project that creates a minimalist application server for smaller applications
that have fewer server requirements.
• A Docker image is a template from which a container can be created.
• OpenShift Contain Platform is a container management tool that utilizes Docker and
Kubernetes to create and manage applications.
• The Red Hat xPaaS is a rich set of application development and integration container images
to help users deploy enterprise-scale applications on Openshift Container Platform.
JB348-RHJBEAP7-en-6-20170411 137
138
TRAINING
CHAPTER 5
CONFIGURATION AND
MANAGEMENT SCRIPTING WITH
CLI
Overview
Goal Given a properly installed JBoss EAP, script various
configuration and management scenarios using CLI.
Objectives • Demonstrate an understanding of the CLI scripting
language and tools.
• Combine multiple CLI commands together in a single

script.
• Manage EAP resources using EAP CLI.

Sections • Scripting with the JBoss EAP CLI (and Guided Exercise)
• Reviewing Configuration and Management Examples (and

Guided Exercise)
• Scripting Common Tasks (and Guided Exercise)

Lab • Configuration and Management Scripting with CLI
JB348-RHJBEAP7-en-6-20170411 139
Chapter 5. Configuration and Management Scripting with CLI
Scripting with the JBoss EAP CLI
Objectives
After completing this section, students will be able to demonstrate an understanding of the CLI
scripting language and tools.
Review the CLI

The Command Line Interface tool, or CLI, allows users to remotely manage and configure EAP
managed domains and standalone instances. This technology allows users to create a batch of
commands in a CLI script for repetitive tasks. With the EAP CLI, it is possible to manage anything
that is managed using the web based Management Console, and more. All changes made using
CLI are written to XML configuration files.
Dynamic Model Representation, or DMR, is the syntax for representing the EAP configuration
objects. Here is a comparison of the XML configuration file standalone.xml and DMR, each
written for the logging subsystem:
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
...remainder of the logging subsystem
</subsystem>
"logging" => {
"add-logging-api-dependencies" => true,
"use-deployment-logging-config" => true,
"async-handler" => undefined,
"console-handler" => {"CONSOLE" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}},
...remainder of the logging subsystem
Observe that DMR shows all parameters, while the XML hides those that are undefined or those
that have a default value.
To get the DMR, users can use the CLI tool with the read-resource operation:
[student@workstation bin]$ ./jboss-cli.sh --connect --controller=172.25.250.254
140 JB348-RHJBEAP7-en-6-20170411
Review the CLI
[standalone@172.25.250.254:9990 /] /subsystem=logging:read-resource(recursive=true)
The script to start the CLI environment is located at JBOSS_HOME/bin. If the --connect option
is not provided, the connect command in the CLI shell is required in order to connect to an EAP
instance. The --controller parameter specifies which EAP instance to connect with the CLI.
The shell offers tab completion just like many operating system shells. Using tab completion is
a great way to learn about the structure of the configuration objects, available operations, and
parameters to operations. An example operation is :read-resource. All operations are issued
after a colon (:), so use tab completion after the colon to see a list of the available commands.
Within the CLI shell, there are two types of requests: commands and operations. Commands
are convenience functions for common tasks and do not require a path to a configuration
object. Operations are appended to the end of a configuration path. For example, connect is an
example of a command and read-resource is an example of an operation.
CLI Invocation Parameters

The CLI invocation script offers several parameters. One of these, --help, gives comprehensive
assistance. The following other parameters are also available:
• --version: Lists version information for EAP and the Java runtime, and related information.
• --connect: Upon entering the shell, connect to the management interface.
• --controller=host[:port]: Give the connection information for the management

interface. Host defaults to localhost and port defaults to 9990.
• --file=file_path: Specifies a path to a file containing commands and operations (one

per line) that should be executed in a non-interactive mode. The CLI terminates the session
immediately after the last command is executed or if some command or operation failed.
• --commands="command,command,...": Execute one or more commands or operations in

sequence and terminate the non-interactive session.
• --command=command: Execute the command or operation and terminate the non-interactive

session.
• --user=username --password=password: Log in to the management interface with

these credentials. This is ignored if the management interface has not been secured.
• --gui: Start the graphical interface.
CLI Authentication
By default, CLI uses silent authentication for local access. Silent authentication allows anyone
access, as long as they are running on the same host as the domain instance, and have local file
access. Remote access is secured out of the box using the same security scheme as the web-
based Management Console, in the mgmt-users.properties file found in the appropriate
configuration folder, such as $JBOSS_HOME/standalone/configuration.
Silent authentication can be removed if desired. To remove silent authentication from a

standalone server, use the following CLI operation:
[standalone@172.25.250.254:9990 /] /core-service=management/security-
realm=ManagementRealm/authentication=local:remove()
JB348-RHJBEAP7-en-6-20170411 141
To remove silent authentication from a managed domain, use the following CLI operation:
[domain@172.25.250.254:9990 /] /host=master/core-service=management\ /security-

realm=ManagementRealm/authentication=local:remove()
Note
This operation selects the host that is designated as domain controller.
Management Resources
The CLI resources are represented as objects. Most of these objects are defined in the
domain.xml or standalone.xml file. The host configuration tree is persisted in the host.xml
file corresponding to the host controller it represents. These are the major objects in the
management resource hierarchy of a managed domain:
• extension: Extensions available in the domain.
• path: Directory paths available across the domain.
• system-property: System properties available across the domain.
• profile: Set of subsystems that can be assigned to server groups.
◦ subsystem: Configuration specific to a particular subsystem.
• interface: Interface configurations.
• socket-binding-group: A group of socket binding configurations that can be applied to

server groups.
◦ socket-binding: Socket binding configuration.
• deployment: instances in some deployment state on the server groups.
• server-group: Server group configuration.
• host: A host controller.
◦ path: Directory paths available to each server controlled by this host.
◦ system-property: System properties that are set on each server controlled by this host.
◦ core-service: Host controller's core services.
◦ interface: Host controller's configured interfaces.
◦ jvm: Java Virtual Machine configurations that are applied when launching servers.
◦ server-config: Configurations that describe how the host controller launches the
server, its server group, and any server-specific overrides.
◦ server: The root resource for running a server. These are not persistent, as they come
from domain and host resource configurations.
142 JB348-RHJBEAP7-en-6-20170411
Operations
▪ extension: Extensions installed on the server.
▪ path: Directory paths available on the server.
▪ system-property: System properties set by configuration.
▪ core-service: Core services for the server.
▪ subsystem: Subsystems installed on the server.
▪ interface: Interface configurations.
▪ socket-binding-group: Socket bindings used by the server.
▪ deployment: Instances in some deployment state on the server.
Note
There is seemingly a duplication of management resources down the hierarchy.
Typically, the management resource of the same name in the highest part of the
hierarchy represents resources that are available. That same resource name appearing
in a server object is the actual implementation of that resource for a given server.
For example, the undertow subsystem is defined in a profile. A profile is assigned
to a server group. A server assigned to that server group inherits its profile, so the
subsystem objects within the server object represent the configuration values and run
time statistics in use on that server.
The management resources for standalone mode are similar to the resources given for domain
mode with some differences. There are no server groups or host controllers in standalone mode.
The server node is treated as the root mode.
Operations
Operations are a low-level way to manage the EAP server. An operation in the CLI has the
following format:
[node] : operation_name [ parameters ] [ headers ]
The node represents a target resource address, or the node, where the operation should be
invoked. It as a key/value pair consisted of the node type and the node name. The node /
subsystem=datasources is a data source.
After specifying the desired node, the operation name should be defined with an optional list of
parameters. The colon is required before the operation name because it serves as a separator
between the node and the operation. A colon (:) is required even if the node is empty. In this
case, the operation is executed in the current node level.
Some common operations:
• :read-resource: Reads a model resource's attribute values, and either basic or complete
information about any child resources.
• :read-operation-names: Gets the names of all the operations for the given resource.
JB348-RHJBEAP7-en-6-20170411 143
• :read-operation-description: Gets the description of a given operation.
• :reload: Reloads the server by shutting down all its services and starting them again. The JVM
itself is not restarted.
• :read-attribute: Gets the value of an attribute for the selected resource.
• :write-attribute: Sets the value of an attribute for the selected resource.
• :remove: Removes the node.
• :add: Adds a new node.
• :take-snapshot: If this operation is executed at the root of the configuration hierarchy it

creates a snapshot in the domain_xml_history/snapshot folder within the appropriate
configuration folder for the domain. Otherwise, it will take the snapshot from the current
node on. The name of the snapshot XML file is given in the output of the operation. This
operation is also available at /host= and will snapshot the host controller XML, such as
host-master.xml, or host-slave.xml.
• :start-servers, :restart-servers, :stop-servers: These operations are available from the root
of the configuration hierarchy and affect all servers in all of the server groups defined in the
domain. In standalone mode, it would affect the server that CLI is connected to.
Standalone Mode
CLI can be used in standalone mode. The location of the configuration differs between nodes.
For example, standalone mode has no concept of server groups or multiple profiles, so the
subsystems configuration is available at the root of the configuration hierarchy in standalone
mode.
144 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Using the CLI Shell
Guided Exercise: Using the CLI Shell
In this exercise, you will use the CLI shell to configure and read information about the cluster.
Resources
Files: /home/student/JB348/labs/using-cli/
Outcomes
You will be able to configure the cluster using the CLI shell.
Before you begin

Use the following command on the workstation VM to set up an EAP cluster with a load
balancer, open firewall ports, and to download the cluster applications:
[student@workstation ~]$ lab using-cli setup

The setup script for this guided exercise downloaded files for a preconfigured managed
domain. This is the same managed domain from the solution of the guided exercise
Troubleshooting JGroups with an additional server group and two more servers, one on
each host. The domain includes a load balancer in front of two host controllers with two
server groups (cluster-group, and cluster-group2) for four servers (cluster-
one, cluster-two, cluster-three, cluster-four), with two servers running on each
servera and serverb hosts.
1.1. Open a new terminal window from workstation and start the load balancer:

-Djboss.server.base.dir=/home/student/JB348/labs/using-cli/lb \

-Djboss.domain.base.dir=/home/student/JB348/labs/using-cli/machine1/ \
SSH:
JB348-RHJBEAP7-en-6-20170411 145

the ssh command:

2. Deploy the Cluster Application

domain controller:

2.2. The CLI shell provides the deploy command to deploy an application. Deploy the
cluster.war application into both server groups:

--server-groups=cluster-group,cluster-group2
Note
The deployment can fail due to an Infinispan timeout. If that happens, run the
deploy command again.
3. Test the cluster

On the workstation VM, open a web browser and navigate to
http://172.25.250.254:9080/cluster. to access the cluster application. Refresh the
page some times and check that the number of visitations increased and that all requests
are being handled by the same node.
4. Read a Resource
A common and useful task with the CLI is reading resource properties to discover or verify
your configurations.
4.1. The CLI input is a hierarchical structure that starts at the domain node for a managed
domain, or the server node in standalone mode:
146 JB348-RHJBEAP7-en-6-20170411
[domain@172.25.250.254:9990 /] /:read-resource
4.2. The forward slash (/) is used to separate levels. For example, the following command
reads the resources of a server named cluster-one available in the host2 host:
[domain@172.25.250.254:9990 /] /host=host2/server-config=cluster-one\
:read-resource
4.3. Add the recursive flag at the end of :read-resource to view a resource and all of
its sub-levels. Compare the output of the following operations:
[domain@172.25.250.254:9990 /] /profile=default/subsystem=undertow:read-resource
[domain@172.25.250.254:9990 /] /profile=default/subsystem=undertow\
:read-resource(recursive=true)
4.4. Add the include-runtime flag at the end of :read-resource to view runtime
information about a resource. Compare the output of the following operations:
[domain@172.25.250.254:9990 /] /host=host2/server=cluster-one/\
subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource
[domain@172.25.250.254:9990 /] /host=host2/server=cluster-one/\
subsystem=datasources/data-source=ExampleDS/statistics=pool\
:read-resource(include-runtime=true)
5. Making Changes in the Cluster

5.1. Before changing the configurations, it is recommended to take a snapshot so that you
have the current configuration available if a restore is required. The CLI shell provides
the :take-snapshot operation to take a snapshot:
[domain@172.25.250.254:9990 /] :take-snapshot
This operation returns the snapshot file path.
Note
There is no operation to restore the configurations from a snapshot. To
restore a configuration, replace the domain.xml from the domain controller
folder with the snapshot file.
5.2. The cluster-one server from the host2 host is not configured to use a port offset.
Configure it to use a port offset of 1000.
[domain@172.25.250.254:9990 /] /host=host2/server-config=cluster-one\
:write-attribute(name=socket-binding-port-offset, value=1000)
5.3. Reload the server to enable the new port offset:
JB348-RHJBEAP7-en-6-20170411 147
[domain@172.25.250.254:9990 /] /host=host2/server-config=cluster-one:reload
5.4. Create a new server with the following characteristics:
• Host: host3
• Name: cluster-five
• Group: cluster-group2
[domain@172.25.250.254:9990 /] /host=host3/server-config=cluster-five\
:add(group=cluster-group2, socket-binding-port-offset=300,auto-start=true)
5.5. The new server is not started by default. This server will auto start only when the host3
host controller is restarted. Start the new server manually:
[domain@172.25.250.254:9990 /] /host=host3/server-config=cluster-five:start

http://172.25.250.11:8380 to test the new server.
5.7. Remove the cluster-two server from the host3 host. Before removing it, stop the
server:
[domain@172.25.250.254:9990 /] /host=host3/server-config=cluster-two:stop
5.8. Remove the server:
[domain@172.25.250.254:9990 /] /host=host3/server-config=cluster-two:remove

6.1. Run the following command to verify that the server was correctly removed.
[student@workstation ~]$ lab using-cli grade
the servers.
148 JB348-RHJBEAP7-en-6-20170411
Reviewing Configuration and Management Examples
Reviewing Configuration and Management

Examples
Objectives
After completing this section, students will be able to batch multiple EAP CLI commands
together.
Batching CLI Commands

It is possible to enter a batch of commands that are executed as a unit. Should any one of
the commands fail, the whole batch is rolled back. The group of operations is executed in the
sequence given. To start a batch of commands in the CLI shell, use the batch command. Enter
all of the commands and operations in the sequence that they are to be executed. When the last
command or operation is entered, issue the run-batch command.
Batch mode is indicated in the CLI shell by the "#" prompt. Here is an example of a session using
a failed batch:
[domain@172.25.250.254:9990 /] batch
[domain@172.25.250.254:9990 / #] /host=host2/server-config=cluster-one:stop
#1 /host=host2/server-config=cluster-one:stop
[domain@172.25.250.254:9990 / #] /host=host3/server-config=cluster-two:start
#2 /host=host3/server-config=cluster-two:start
[domain@172.25.250.254:9990 / #] run-batch
Failed to execute batch: JBAS010850: No handler for operation
start at address [ ("host" =>
"host3"), ("server-config" => "cluster-two")
]
In this case, cluster-one is still running because all of the operations were rolled back.
Sometimes, a batch needs to be paused while, for instance, complex queries are processed. Issue
the holdback-batch command to drop the batch mode. To resume the batch operation, reissue
the batch command.
To see the commands that are currently in the batch queue, use the list-batch command.
Batch mode also provides the following commands:
• edit-batch-line: Edit a batch operation based on its line number.
• move-batch-line: Move a batch operation to a different line within the batch sequence.
• remove-batch-line: Remove a batch operation based on its line.
• discard-batch: Cancel the current batch operations.
Using scripts
There are several ways to script batches of commands:
• --file=parameter
JB348-RHJBEAP7-en-6-20170411 149
Put all of the batch commands and operations in a file starting with batch and ending with
run-batch. The name of the file is unimportant. Execute the CLI shell with the --file
parameter.
./jboss-cli.sh --connect --controller=172.25.250.254 --file=/path/to/script/script.cli
• --commands=parameter
Execute the CLI shell with the --commands parameter. Put a comma-separated list of
commands, operations, or both, in quotes.
./jboss-cli.sh --connect --controller=172.25.250.254 --commands="/host=hos2:shutdown,/

host=host3:shutdown"
{ "outcome" => "success",

"result" => undefined
}
{
"outcome" => "success",
"result" => undefined
}
• Using a command shell script
It is possible to create a command shell script containing one or more executions of the CLI
shell using one or more of the techniques in this section.
150 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Creating a CLI Script
Guided Exercise: Creating a CLI Script
In this exercise, you will create a CLI script using the batch command.
Resources
Files: /home/student/JB348/labs/create-cli-script/
Application URL: NA
Outcomes
You will be able to create scripts that run multiple commands that execute as one atomic unit.
Before you begin

balancer, open firewall ports, and download the cluster applications:
[student@workstation ~]$ lab create-cli-script setup

The setup script for this guided exercise downloaded files for an already configured
managed domain.

-Djboss.domain.base.dir=/home/student/JB348/labs/create-cli-script/machine1/ \
the ssh command:

the ssh command:
JB348-RHJBEAP7-en-6-20170411 151

2. Create a script using the batch command

Create a new server group named production-group using the ha profile. The new server
group has two servers with the following characteristics:
• Server One:
◦ Host: host2
◦ Name: server-one
◦ Group: production-group
◦ Port offset: 0
◦ Auto start: true
• Server Two:
◦ Host: host3
◦ Name: server-two
◦ Port offset: 0
2.1. In a new terminal window on the workstation, use a text editor and create the /
home/student/JB348/labs/create-cli-script/script.cli file.
Note
The each command must be added to the script.cli file as a single line.
2.2. The CLI has a batch command that allows you to enter multiple commands that
execute as one atomic unit. If at least one of the commands or operations fails, all the
other successfully executed commands and operations in the batch are rolled back. In
the script.cli file, add the batch command:
batch
2.3. On the next line of the script.cli file, add the operation to create the new server
group:
/server-group=production-group:add(profile=ha,socket-binding-group=ha-sockets)
2.4. Navigate to the host2 host to create the server-one server:
152 JB348-RHJBEAP7-en-6-20170411
cd /host=host2
2.5. Create the server-one server:
./server-config=server-one:add(group=production-group, auto-start=true, socket-

binding-port-offset=0)
2.6. Navigate to the host3 host to create the server-two server:
cd /host=host3
2.7. Create the server-two server:
./server-config=server-two:add(group=production-group, auto-start=true, socket-

2.8. Use the run-batch command to execute the batch file:
run-batch
2.9. Start the servers:
/host=host2/server-config=server-one:start(blocking=true)
/host=host3/server-config=server-two:start(blocking=true)
Note
The servers can only be started after the batch completes.
2.10.An example script.cli batch script:
batch
/server-group=production-group:add(profile=ha,socket-binding-group=ha-sockets)
cd /host=host2
./server-config=server-one:add(group=production-group, auto-start=true, socket-

cd /host=host3
./server-config=server-two:add(group=production-group, auto-start=true, socket-

run-batch
/host=host2/server-config=server-one:start(blocking=true)
JB348-RHJBEAP7-en-6-20170411 153
/host=host3/server-config=server-two:start(blocking=true)
3. Open a terminal window from the workstation VM and execute the script:

[student@workstation ~]$ ./jboss-cli.sh -c --controller=172.25.250.254:9990 \
--file=/home/student/JB348/labs/create-cli-script/script.cli
4. Check the Group and the New Servers

4.1. Start the EAP CLI and connect to the domain controller:
4.2. Check that the production-group group was created:
[domain@172.25.250.254:9990 /] /server-group=production-group:read-resource
4.3. Verify that server-one was created and that it is running:
[domain@172.25.250.254:9990 /] /host=host2/server=server-one\
:read-attribute(name=server-state)
4.4. Verify that server-two was created and that it is running:
[domain@172.25.250.254:9990 /] /host=host3/server=server-two\
:read-attribute(name=server-state)

created.
[student@workstation ~]$ lab create-cli-script grade
the servers.
154 JB348-RHJBEAP7-en-6-20170411
Scripting Common Tasks
Scripting Common Tasks
Objectives
After completing this section, students should be able to manage EAP resources using the EAP
CLI.
Examples of Common Scripting Tasks

The CLI shell combined with a command shell script allows users to create scripts for repetitive
tasks like deploying an application, creating a datasource, and monitoring servers.
Application Deployment
Given the convenient CLI commands deploy, undeploy, and deployment-info, it is easy to
write deployment scripts.
Here is a script, deploy.sh, to deploy an application to a particular server group in a domain:
#!/bin/bash
CLI_COMMAND="/opt/jboss-eap-7.0/bin/jboss-cli.sh -c --controller=172.25.250.254"
APPLICATION=$1
JBOSS_GROUP=$2
NEWAPPLICATIONPATH=$3/$1
deploy(){
deploy_app
if [ $? -ne 0 ]
then
exit 1
fi
echo -e
}
deploy_app(){
$CLI_COMMAND --commands="deploy $NEWAPPLICATIONPATH --server-groups=
$JBOSS_GROUP,deployment-info -- name=$APPLICATION"
}
echo Deploying $NEWAPPLICATIONPATH

echo -e
deploy
exit 0
Similarly, the following script, undeploy.sh, undeploys the application from all server groups
and removes it from the content cache on the domain controller:
#!/bin/bash
APPLICATION=$1
undeploy()
{
undeploy_app
if [ $? -ne 0 ]
then
exit 1
JB348-RHJBEAP7-en-6-20170411 155
fi
echo -e
}
undeploy_app()
{
$CLI_COMMAND --command="undeploy --name=$APPLICATION --all-relevant-server-groups"
echo Undeploying $APPLICATION
echo -e
undeploy
exit 0
Data source Definition

Data source definitions are usually created by administrators when developers introduce new
schemas into applications deployed on EAP. It is likely that many data source definitions will be
for the same database server type. Use a script to create a template for these datasources. The
following script, createDS.sh, is a template script for creating a data source:
#!/bin/bash
PROFILE=$1
JNDI_NAME=$2
POOL_NAME=$3
CONNECTION_URL=$4
USER_NAME=$5
PASSWORD=$6
DRIVER=$7
function usage
{
echo "Usage:"
echo "datasource.sh <profile> <jndi-name> <pool-name> <connection-url> <user-name>
<password> <driver>"
echo "This script creates a datasource on an EAP 7 domain."
echo -e
}
function create_datasource
{
echo
echo "Creating the $POOL_NAME datasource"
DS_COMMAND="data-source add --profile=$PROFILE --name=$POOL_NAME --jndi-name=
$JNDI_NAME --user-name=$USER_NAME --password=$PASSWORD --connection-url=$CONNECTION_URL
--driver-name=$DRIVER --statistics-enabled=true"
RESULT=`$CLI_COMMAND command="$DS_COMMAND"`
if [ $? -eq 0 ] ; then
echo
echo "Datasource created successfully."
else
echo
echo "Failed to create a datasource. "
echo "$RESULT"
fi
156 JB348-RHJBEAP7-en-6-20170411
if [ $# -ne 7 ]
then
usage
exit 7
else
create_datasource
fi
Query Management to monitor Resources

Querying management resources, such as monitoring a pool from a datasource, is an important
administration task. Users can create a script in order to monitor a specific resource and execute
it using the cron task manager at a specified time interval.
The following is a script that monitors a datasource from all of the servers that belong to a
specific server group:
#!/bin/bash
SERVER_GROUP=$1
DATASOURCE=$2
MAX=$3
function monitor_datasource
{
HOSTS=`$CLI_COMMAND --command="ls /host"`
for HOST in $HOSTS ; do
SERVERS=`$CLI_COMMAND --command="ls /host=$HOST/server-config"`
for SERVER in $SERVERS ; do
GROUP=`$CLI_COMMAND --command="/host=$HOST/server-config=$SERVER:read-
attribute(name=group)" | awk '/result/{gsub("\"", "", $3); print $3}'`
if [[ "$GROUP" == "$SERVER_GROUP" ]] ; then
IN_USE=`$CLI_COMMAND --command="/host=$HOST/server=$SERVER/
subsystem=datasources/data-source=$DATASOURCE/statistics=pool:read-
attribute(name=InUseCount)" | awk '/result/{gsub("\"", "", $3); print $3}'`
if [[ $IN_USE > $MAX ]] ; then
mail -s "Problem with Datasource $DATASOURCE" "admins@example.com" <<EOF
The $DATASOURCE is using a lot of connections. Please verify
EOF
fi
fi
done
done
}
function usage
{
echo "Usage:"
echo "monitorDS.sh <server-group> <data-source> <max-connections>"
echo "This script get information about datasource and alert the administrators if the
number of in use connections are high."
echo -e
}
if [ $# -ne 3 ]
then
usage
exit 3
JB348-RHJBEAP7-en-6-20170411 157
else
monitor_datasource
fi
Add a module
Adding a module is another repeatable task that administrators may want to consider creating a
script for. The following script adds a new module:
#!/bin/bash
MODULE_NAME=$1
JAR_PATH=$2
DEPENDENCIES=$3
function add_module
{
$CLI_COMMAND --command="module add --name=$MODULE_NAME --resources=$JAR_PATH --
dependencies=$DEPENDENCIES"
}
function usage
{
echo "Usage:"
echo "module.sh <module-name> <jar-path> <dependencies>"
echo "This script will create a new module."
echo -e
}
if [ $# -ne 3 ]
then
usage
exit 3
else
add_module
fi
Add a server
Users can use the following script to automate the creation of servers:
#!/bin/bash
SERVER_GROUP=$1
AUTO_START=$2
PORT_OFFSET=$3
HOST=$4
NAME=$5
function add_server
{
$CLI_COMMAND --command="/host=$HOST/server-config=$NAME:add(group=$SERVER_GROUP, auto-
start=$AUTO_START, socket-
binding-port-offset=$PORT_OFFSET)"
}
function usage
{
echo "Usage:"
158 JB348-RHJBEAP7-en-6-20170411
echo "server.sh <server-group> <auto-start> <port-offset> <host> <name>"

echo "This script will create a server."
echo -e
}
if [ $# -ne 5 ]
then
usage
exit 5
else
add_server
fi
Patching
To quickly patch EAP, users can use the following script to patch the specified EAP instance:
#!/bin/bash
PATCH_PATH=$1
function apply_patch
{
$CLI_COMMAND --command="patch apply $PATCH_PATH --override-all"
}
function usage
{
echo "Usage:"
echo "patch.sh <patch-path>"
echo "This script will apply a patch."
echo -e
}
if [ $# -ne 1 ]
then
usage
exit 1
else
apply_patch
fi
Restarting
Administrators occasionally need to restart all servers from a server group when applying
updates. The following is a script, restart.sh, to restart all servers that belong to a server
group:
#!/bin/bash
SERVER-GROUP=$1
function restart
{
$CLI_COMMAND --command="/server-group=$SERVER-GROUP:stop-servers"
$CLI_COMMAND --command="/server-group=$SERVER-GROUP:start-servers"
}
JB348-RHJBEAP7-en-6-20170411 159
function usage
{
echo "Usage:"
echo "restart.sh <server-group>"
echo "This script will apply a patch."
echo -e
}
if [ $# -ne 1 ]
then
usage
exit 1
else
restart
fi
CLI commands in offline mode

JBoss EAP 7 has a new management mode for the CLI, allowing users to start an embedded
instance from the CLI. This is useful when administrators need to prepare some configuration
without changing the production environment.
To start using the offline mode, execute the CLI without the -c parameter:
[student@workstation bin]$ sudo -u jboss /opt/jboss-eap-7.0/bin/jboss-cli.sh
The embed-server command is responsible for starting an embedded server to perform offline
configurations. By default, the changes are applied in the standalone.xml configuration file
available in the standalone folder from the JBoss installation path
It is possible to define the desired file with the --server-config parameter. The file must
already exist on the standalone folder.
It is also possible to start an embedded process to configure the managed domain mode with the
embed-host-controller command.
160 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Common Task Scripts
Guided Exercise: Common Task Scripts
In this exercise, you will create and explore scripts for common EAP administration tasks.
Resources
Files: /home/student/JB348/labs/common-scripts
Application URL: http://172.25.250.254:9080/database
Outcomes
You will be able to create scripts for common EAP administration tasks.
Before you begin

balancer, open firewall ports, and download the cluster application:
[student@workstation ~]$ lab common-scripts setup

The set up script for this guided exercise downloaded files for a preconfigured managed
domain.
1.1. Open a new terminal window on workstation and run the following command to start
the load balancer:

-Djboss.server.base.dir=/home/student/JB348/labs/common-scripts/lb \

-Djboss.domain.base.dir=/home/student/JB348/labs/common-scripts/machine1/ \
1.3. Open a terminal window on the workstation VM and access the servera VM using
SSH:

JB348-RHJBEAP7-en-6-20170411 161
the ssh command:

2. A nonfunctional Bash shell script named datasource.sh is provided in the /home/

student/JB348/labs/common-scripts folder. Use this script as a starting point to
create a new data source.
2.1. Before updating the shell script, open a terminal window from the workstation and
try to execute it:
[student@workstation ~]$ cd JB348/labs/common-scripts

[student@workstation common-scripts]$ ./datasource.sh
The output asks for 7 arguments:
Usage:
datasource.sh <profile> <jndi-name> <pool-name> <connection-url> <user-name>
<password> <driver>
This script creates a datasource on an EAP 7 domain.
2.2. Update the script so that it distribute each argument into the appropriate variable. The
first argument is represented by $1 in the script. The second one is represented by $2,
and so on:
PROFILE=$1
JNDI_NAME=$2
POOL_NAME=$3
CONNECTION_URL=$4
USER_NAME=$5
PASSWORD=$6
DRIVER=$7
2.3. On line 28, inside the DS_COMMAND variable, add the data-source command to create
a datasource according to the passed arguments:
DS_COMMAND="data-source add --profile=$PROFILE --name=$POOL_NAME --jndi-

name=$JNDI_NAME --user-name=$USER_NAME --password=$PASSWORD --connection-url=
$CONNECTION_URL --driver-name=$DRIVER --statistics-enabled=true"
162 JB348-RHJBEAP7-en-6-20170411
Note
Type the previous line as a single line in the file.
2.4. Save the changes and close the file.
3. Create a new data source using the following arguments:
• Profile: ha
• Jndi name: java:jboss/datasources/database
• Pool name: database
• Connection url: jdbc:h2:mem:database;DB_CLOSE_DELAY=-1
• Username: sa
• Password: sa
• Driver: h2
Note
Pay attention to the "" required by the connection URL and JNDI name. Quotes
are required here so Bash recognizes them as a single argument.
[student@workstation common-tasks]$ ./datasource.sh ha \

"java:jboss/datasources/database" database \
"jdbc:h2:mem:database;DB_CLOSE_DELAY=-1" sa sa h2
4. The database.war application requires the datasource created in the previous step. Deploy
the application:
[student@workstation common-scripts]$ cd /opt/jboss-eap-7.0/bin

4.2. Deploy the database.war application:
[domain@172.25.250.254:9990 /] deploy /home/student/JB348/apps/database.war \

JB348-RHJBEAP7-en-6-20170411 163
Note
The deployment can fail due to an Infinispan timeout. If that happens, run the
5. On the workstation VM, open a web browser and navigate to

http://172.25.250.254:9080/database to see the database web UI. Select a
category and click Search courses. A list of courses assigned to the selected category is
displayed.
To generate information to monitor later in this exercise, repeat this test a few times. Click
Kill Session to end the session.
6. A nonfunctional Bash shell script named monitoring.sh is provided in the /home/

student/JB348/labs/common-scripts folder. Use this script as a starting point to get
information about the data source, web sessions, and JVM usage from servers in a server-
group within an EAP 7 domain.
6.1. Using your preferred text editor, edit the monitoring.sh script. On line 25 set the
IN_USE variable to an operation that recovers the number of connections that are in
use:
IN_USE=`$CLI_COMMAND --command="/host=$HOST/server=$SERVER/
subsystem=datasources/data-source=$DATASOURCE/statistics=pool:read-
attribute(name=InUseCount)" | awk '/result/{gsub("\"", "", $3); print $3}'`
6.2. On line 54, set the ACTIVE_SESSIONS variable to an operation that recovers the
number of active sessions for each application:
ACTIVE_SESSIONS=`$CLI_COMMAND
--command="/host=$HOST/server=$SERVER/deployment=$APP/
subsystem=undertow:read-attribute(name=active-sessions)"
| awk '/result/{gsub("\"", "", $3); print $3}'`
6.3. On line 82, set the HEAP variable to an operation that recovers information about the
JVM Heap usage:
HEAP=`$CLI_COMMAND --command="/host=$HOST/server=$SERVER/core-service=platform-
mbean/type=memory:read-attribute(name=heap-memory-usage)"`
6.4. Save the changes and close the file.
7. Open a terminal window from the workstation and execute the script to get information
about the cluster-group group:
[student@workstation ~]$ cd JB348/labs/common-scripts

[student@workstation common-scripts]$ ./monitoring.sh cluster-group
164 JB348-RHJBEAP7-en-6-20170411
The output displays information about data source, web session, and JVM usage from all
servers that belongs to the cluster-group group.
8. Grade and Clean Up

8.1. Run the following command to verify that the server was correctly migrated.
[student@workstation ~]$ lab common-scripts grade
8.2. Press Ctrl+C in the terminal window running EAP 7 to stop the servers.
JB348-RHJBEAP7-en-6-20170411 165
Lab: Configuration and Management Scripting

with CLI
In this lab, you will create and explore scripts for common EAP administration tasks, such as
creating servers and server groups. Scripting these, and other repetitive tasks, makes the job of
administration easier and helps avoid typos.
Resources
Files: /home/student/JB348/labs/script-cli, /tmp/
script.war
Application URL: http://172.25.250.10:8280/script
http://172.25.250.11:8280/script
Outcomes
You will be able to create a script that will configure a managed domain.
Before you begin

Use the following command to verify that an instance of EAP is installed in the /opt directory
and download the required files for this exercise:
[student@workstation ~]$ lab script-cli setup

Start the domain controller on workstation with the host-master.xml host
configuration file and set the base directory as /opt/domain.
each to /opt/domain and set the node name to be servera or serverb depending on
2. Edit the /home/student/JB348/labs/script-cli/script.cli script. The script

should use batch commands and should run the following tasks:
2.1. Create a new server group with the following characteristics:
• Name: script-group
• Profile: default
• Socket binding group: standard-sockets
Note
Add the server-group command as a single line.
2.2. Create a server with the following characteristics:
166 JB348-RHJBEAP7-en-6-20170411
• Host: servera
• Name: script-one
• Group: script-group
• Auto start: false
Note
• Host: serverb
• Name: script-two
Note
2.4. Deploy the /home/student/JB348/apps/script.war application into script-

group group.
Important
Run the batch before deploying the application.
3. Execute the script to modify the managed domain.
4. Using the EAP CLI, start the script-one and script-two servers.
5. Verify that you can access the script.war application on all servers you created in the above
steps. Access the following URLs:
• http://172.25.250.10:8280/script
• http://172.25.250.11:8280/script
JB348-RHJBEAP7-en-6-20170411 167

[student@workstation ~]$ lab script-cli grade
168 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
In this lab, you will create and explore scripts for common EAP administration tasks, such as
creating servers and server groups. Scripting these, and other repetitive tasks, makes the job of
administration easier and helps avoid typos.
Resources
Files: /home/student/JB348/labs/script-cli, /tmp/
script.war
Application URL: http://172.25.250.10:8280/script
http://172.25.250.11:8280/script
Outcomes
You will be able to create a script that will configure a managed domain.
Before you begin

Use the following command to verify that an instance of EAP is installed in the /opt directory
and download the required files for this exercise:
[student@workstation ~]$ lab script-cli setup

each to /opt/domain and set the node name to be servera or serverb depending on
On the workstation:
student@workstation ~]$ cd /opt/jboss-eap-7.0/bin

[student@workstation bin]$ sudo -u jboss ./domain.sh \
On servera:

On serverb:

JB348-RHJBEAP7-en-6-20170411 169
2. Edit the /home/student/JB348/labs/script-cli/script.cli script. The script

should use batch commands and should run the following tasks:
2.1. Create a new server group with the following characteristics:
• Name: script-group
• Profile: default
• Socket binding group: standard-sockets
batch
/server-group=script-group:add(profile=default,socket-binding-group=standard-
sockets)
Note
• Host: servera
• Name: script-one
/host=servera/server-config=script-one:add(group=script-group, auto-start=false,
socket-binding-port-offset=200)
Note
• Host: serverb
• Name: script-two
170 JB348-RHJBEAP7-en-6-20170411
Solution
/host=serverb/server-config=script-two:add(group=script-group, auto-start=false,
Note
2.4. Deploy the /home/student/JB348/apps/script.war application into script-

group group.
run-batch
deploy /home/student/JB348/apps/script.war --server-groups=script-group
Important
Run the batch before deploying the application.
The final script.cli file should have the following content:
batch
/server-group=script-group:add(profile=default,socket-binding-group=standard-
sockets)
/host=servera/server-config=script-one:add(group=script-group, auto-start=false,
/host=serverb/server-config=script-two:add(group=script-group, auto-start=false,
run-batch
deploy /home/student/JB348/apps/script.war --server-groups=script-group
3. Execute the script to modify the managed domain.

[student@workstation ~]$ ./jboss-cli.sh -c --controller=172.25.250.254:9990 \
--file=/home/student/JB348/labs/script-cli/script.cli
4. Using the EAP CLI, start the script-one and script-two servers.
4.2. Start the script-one server:
[domain@172.25.250.254:9990 /] /host=servera/server-config=script-one\
:start(blocking=true)
JB348-RHJBEAP7-en-6-20170411 171
4.3. Start the script-two server:
[domain@172.25.250.254:9990 /] /host=serverb/server-config=script-two\
5. Verify that you can access the script.war application on all servers you created in the above
steps. Access the following URLs:
• http://172.25.250.10:8280/script
• http://172.25.250.11:8280/script

[student@workstation ~]$ lab script-cli grade
172 JB348-RHJBEAP7-en-6-20170411
Summary
Summary
• The Command Line Interface tool, or CLI, allows users to remotely manage and configure EAP
managed domains and standalone instances.
• By default, CLI uses silent authentication for local access but this behavior can be changed.
• The CLI resources are represented as objects. Most of these objects are saved in the
domain.xml or standalone.xml file.
• Running batch mode to execute several commands as a single unit ensures that if any one
command fails, the whole batch is rolled back.
• CLI provides commands that are easier to use than running related commands with
operations.
• CLI Shell combined with a command shell script allows an administrator to create scripts for
repetitive tasks.
JB348-RHJBEAP7-en-6-20170411 173
174
TRAINING
CHAPTER 6
MONITORING AND
MANAGEMENT
Overview
Goal Given a properly configured JBoss EAP in standalone or a
managed domain, use various tools to monitor and manage
EAP.
Objectives • Review features of the EAP Management Console.
• Define the functionality and features of the management

API.
• Create custom tools using the native management API.
• Monitor EAP using JMX.

Sections • Describing the Features of the EAP Management Console
• Defining the Features of the Management API (and Guided

Exercise)
• Utilizing the Native Management API (and Quiz)
• Configuring Custom Services with JMX (and Guided

Exercise)
Lab • Monitoring and Management
JB348-RHJBEAP7-en-6-20170411 175
Chapter 6. Monitoring and Management
Describing the Features of the EAP

Management Console
Objectives
After completing this section, students should be able to manage an EAP instance with the EAP
Management Console.
The EAP Management Console

The web-based Management Console, located by default at port 9990, provides a customized
user interface for managing and monitoring many of EAP's resources. Not all management
resources are represented in the console at this time. CLI can be used to access all of the
management resources.
The Management Console accesses the same management resource model as the CLI through
the management HTTP REST API. CLI uses the native Java API. The console is secured by default
with a challenge and response scheme. User accounts are maintained in the configuration/
mgmt-user.properties file. The recommended method to add or change accounts is through
the bin/add-user.sh (or add-user.bat, on Windows) script. Security is addressed in greater
detail in a later chapter.
All changes made to the management console are written to the domain, host, or standalone
XML files, depending on the type of objects changed and the EAP mode being used. Messages in
the console indicate whether a restart is required for the configuration changes to take effect.
Note
Throughout the various pages in the Management Console is the link Need Help?. Use
this link to display context-sensitive information about the page.
Management Console in Domain Mode

The Management Console displays a different set of sections when EAP is running in a managed
domain. There are three tabs:
• Profiles
• Server
• Runtime
The primary difference in the console between the standalone mode and a managed domain
is the existence of multiple profiles and multiple servers across server groups. Users must
first select the profile, host, or server to indicate which configurations are being examined or
changed.
In a managed domain, users are allowed to start and stop individual servers. Users cannot do this
in standalone mode because there is no concept of a host controller that manages the server,
although an individual standalone server can be restarted.
176 JB348-RHJBEAP7-en-6-20170411
Demonstration: Management Console Review
Demonstration: Management Console Review

1. Run the following command to verify that a managed domain is installed in the correct
location, and that no instance of EAP is running
[student@workstation ~]$ demo console-review setup
2. Run the following command in a terminal window on workstation to start the domain
controller:

3. In a web browser on workstation, navigate to 172.25.250.254:9990 to access the

management console. Use these credentials to log in:
4. Click Configuration at the top of the page.
5. Click Profiles in the first column, and then click full-ha. Click Clone.
6. In the clone dialog, enter the name full-ha-debug and then click Create new profile.
7. In the full-ha-debug profile, click Logging and then click View.
8. Click Handler and in the Console handler settings, click Edit to edit the Level to be DEBUG.
Then click Save.
9. Click Root Logger and then click Edit under Attributes. Change the Level to DEBUG and
then click Save.
10. Click Back and then click Runtime at the top of the page.
11. Click Server Groups and click Group1. Click View.
12. Click Edit and set the profile to the new profile full-ha-debug. Click Save.
13. Open a new terminal window and run the following command in servera to start the host
controller on Server A.

14. Verify that the server in Group1 now outputs debug logs into the console.
JB348-RHJBEAP7-en-6-20170411 177
15. Press Ctrl+C in the terminal windows where you started the cluster instances of EAP to
stop the cluster.
178 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Changing Logging Levels
Guided Exercise: Changing Logging Levels
In this exercise, you will use the management console to update logging levels and cloning a
profile.
Resources
Files: /opt/domain/
Application URL: 172.25.250.254:9990
Outcomes
You will be able to clone a profile and update logging levels.
Before you begin

installed in the /opt/ directory and to download the server configuration files for this exercise:
[student@workstation ~]$ lab log-levels setup

Run the following command in a terminal window on workstation to start the domain
controller:

2. Access the Management Console

In a web browser on workstation, navigate to 172.25.250.254:9990 to access the
management console. Use these credentials to log in:
3. Clone the full-ha Profile

Clone the full-ha profile with the new name full-ha-trace. In this profile, you will
increase the logging level to use it temporarily as a means of debugging.
Click Configuration at the top of the page. Click Profiles in the first column, and then click
full-ha. Click Clone. In the clone dialog, enter the name full-ha-trace.
4. Adjust ActiveMQ Artemis Logging Level

4.1. In the full-ha-trace profile, click Logging and then click View.
4.2. In the Logging subsystem view, click Log Categories.
4.3. Click Add to add a new log category.
4.4. Add the following values in the Create LOGGER window:

• Name: org.apache.activemq
JB348-RHJBEAP7-en-6-20170411 179
• Category: org.apache.activemq
• Handlers: CONSOLE
• Level: TRACE
• Use parent handlers: unselected
4.5. Click Save.
5. Configure Server Profiles

After creating the new debug profile, attach the profile to all servers in the Group1 server
group.
5.1. Click Back. Click Runtime at the top of the management console, and then click Server
Groups and click Group1. Click View.
5.2. Click Edit and set the profile to the new profile full-ha-trace. Click Save.
6. Start the Host Controllers

6.1. Open a new terminal window and run the following command in servera to start the
host controller on servera:

6.2. Open a new terminal window and run the following command in serverb to start the
host controller on serverb.

6.3. Observe the output in the log console. The output level has not increased with more
output for the org.apache.activemq category. This is because the CONSOLE handler
is still not configured for a TRACE log level.
6.4. Return to the management console. Click Handler in the logging subsystem. In the
Console handler, click Edit and change the level to TRACE. Click Save.
6.5. Verify that the output from the servers now displays the trace-level logging for the
org.apache.activemq category.
6.6. Press Ctrl+C in the terminal window for each host controller on servera and
serverb.
180 JB348-RHJBEAP7-en-6-20170411
7. Revert the Profile for Server Group 1
Use the management console to revert the profile of Group1 back to full-ha.
7.1. Click Runtime at the top of the management console, and then click Server Groups and
click Group1. Click View.
7.2. Click Edit and set the profile to full-ha. Click Save.

[student@workstation ~]$ lab log-levels grade
8.2. Press Ctrl+C in the terminal window where you started the domain controller on the
workstation.
JB348-RHJBEAP7-en-6-20170411 181
Defining the Features of the Management API
Objectives
After completing this section, students will be able to define the functionality and the features of
the management API.
The Management API

Many administrators want to be able to make custom components for managing EAP to fill in
specific needs for their organization. This can range from creating custom scripts for monitoring
resources, or creating applications that can simplify repeatable tasks. EAP's management API
provides the capability for administrators to directly interact with EAP management, making
it simpler to create custom components. This is the same API that is used by the Management
Console and CLI. This section takes a closer look at the functionality of the management API and
its data structures.
DMR
In a typical application programming interface (API), each one of these concepts would be
represented by a custom data structure. This increases the complexity of creating custom clients
using this API because they require access to these custom data structures, and the client
programs are dependent upon a particular version of the API. Additionally, as the API evolves,
code changes are forced upon the developer.
The management model exposed by EAP 7 is large and complex, with a number of concepts
involved, including hosts, server groups, servers, and subsystems. When EAP was being created,
the idea of a de-typed management representation, or DMR, was born. The idea is to build
complex data structures using a small number of Java data types. The result is a lightweight
client library called jboss-dmr. When users invoke operations using the CLI, the return values
are text representations of a ModelNode. Every management resource in CLI is represented in
DMR by the ModelNode class.
The following is a snippet of a groovy script that lists all of the hosts in a managed domain:
result = cli.cmd("/host=" + host.asString() + "/:read-children-names(child-

type=server)")
if (result.isSuccess()) {
for (server in result.getResponse().get("result").asList()) {
The following code exposes the ModelNode a little better:
result = cli.cmd("/host=" + host.asString() + "/:read-children-names(child-

type=server)")
if (result.isSuccess()) {
ModelNode node = result.getResponse().get("result")
for (server in node.asList()) {
Almost every API invocation yields its result as a ModelNode.
ModelNode and ModelType

A ModelNode is a wrapper around a value. This value can have one of many types:
• BIG_DECIMAL
182 JB348-RHJBEAP7-en-6-20170411
The Management API
• BIG_INTEGER
• BOOLEAN
• BYTES
• DOUBLE
• EXPRESSION
• INT
• LIST
• LONG
• OBJECT
• PROPERTY
• STRING
• TYPE
• UNDEFINED
Calling the getType( ) method on the ModelNode returns one of these types as
an enumeration, ModelType. A newly initialized node has no value, so its type is
ModelType.UNDEFINED. A node's value is assigned by using one of the many overloaded
set( ) methods. The node's value type is determined by which set( ) method is called. For
example:
ModelNode node = new ModelNode();

print(node.getType()); // prints UNDEFINED
node.set("Hello");
print(node.getType()); // prints STRING
node.set(true);
print(node.getType()); // prints BOOLEAN
A node can also be constructed with one of its many overloaded constructors. The value type is
determined by the constructor used.
To retrieve the value of a node, use one of the as methods:

• asBigDecimal( )
• asBigInteger( )
• asBoolean( )
• asBytes( )
• asDouble( )
• asInt( )
• asList( )
JB348-RHJBEAP7-en-6-20170411 183
• asLong( )
• asObject( )
• asProperty( )
• asPropertyList( )
• asString( )
• asType( )
If an as method called does not correlate to value type of the node, a conversion is attempted:
node.set(1); // set to the integer 1

print(node.asBoolean()); // prints true
Expressions
A node of type ModelType.EXPRESSION is stored as a string, but can be resolved to a different
value by substituting the current value of a system property named within the expression. The
string must use a special syntax:
[<prefix>][${<system-property-name>[:<default-value>]}][<suffix>]
For example:
http://${host:localhost}:${port:8080}/index.html
Use the setExpression( ) method to set a node's value and mark its type as an expression.
Call the resolve( ) method to generate a new STRING node with the values of the system
properties embedded in the expression replaced with their current value or the default value, if
given. For example:
ModelNode expression = new ModelNode();

expression.setExpression("http://${host:localhost}:${port:8080}/index.html");
System.setProperty("host", "xyz.com");
ModelNode resolved = expression.resolve();
print(resolved.asString()); // prints http://xyz.com:8080/index.html
Lists
A node of type ModelType.LIST contains a list of ModelNode. Use one of the overloaded
add( ) methods to add a value to the list. When the first item is added, the node's type is set to
LIST. Use the asInt( ) method to get the current size of the list. There is no requirement that
all the list elements be of the same type. Since each element of the list is its own ModelNode,
users can check the element's type with getType( ).
Use the get( ) method to get a particular element in the list. The get( ) method is not
necessarily "read-only". For example:

node.add("First");
print(node.get(3)); // prints UNDEFINED
print(node.asInt()); // prints 3 - the size of the list is now 4!!!
print(node.get(2)); // prints UNDEFINED
184 JB348-RHJBEAP7-en-6-20170411
The Management API
Getting an element that does not exist results in an UNDEFINED node being inserted and other
UNDEFINED nodes added as needed to make a list of that size. Attempting to get an element on a
node that is not of type LIST, forces the object to become a list.
Insight
List indexes start with zero. To get the first item in the list: node.get(0)
Use the asList( ) method to get a list of elements on which to iterate:
for(ModelNode element : list.asList()) {

print(element.asString());
}
If the node is initialized to a type other than LIST, users cannot add items to that node. Users
can call setEmptyList( ) to initialize the node to an empty list and then proceed to add
elements to the list.
Objects
A node of type ModelType.OBJECT contains a map: Map<String, ModelNode>. The object is a set
of values (ModelNode) indexed by a unique string identifier, making this the most versatile and
widely used node type throughout the management model. Use the get( ) method passing in
the unique string to get that particular value of the object. For example:
ModelNode person = new ModelNode();

ModelNode name = person.get("firstName");
print(name.asString()); // prints UNDEFINED
name.set("John");
person.get("lastName").set("Doe");
print(person.toString());
The get( ) method creates and return an UNDEFINED node for the given key value if it does
not already exist. This makes method chaining possible. For example:
person.get("lastName").set("Doe");
It is very common in the EAP model for one object to point to another which points to yet
another. These relationships form trees like the management resource tree accessed in CLI
through paths: /host=host1/server=server1:read-resource. A special get( ) method
can traverse these paths. This overloaded form of get takes a variable sized list of string key
values. The first key string gets to the first object, the second key string gets an object from the
first, and so forth. Just as with other DMR getter methods, this one creates a node if it is not
found. For example:
ModelNode result =
node.get("Parent","Child","Grandchild"); result.set("Jane
Doe");
The values of the object can be accessed as key-value pairs:
for(Property prop : node.asPropertyList()) {

print(prop.getName() + " = " + prop.getValue());
JB348-RHJBEAP7-en-6-20170411 185
Use has( ) and hasDefined( ) to check if a value is present without unintentionally creating
an undefined value:

node.get("name").set("Mary");
node.get("age");
print(node.has("age")); // prints true
print(node.hasDefined("age")); // prints false
Properties
A node of type ModelType.PROPERTY contains a DMR Property (org.jboss.dmr.Property).
A Property contains a "name" part and a "value" part. When a node has its value set to a
property, it becomes a node of type PROPERTY.
ModelNode list = new ModelNode();

list.add(1);
list.add(2);
list.add("Hello");
Property prop = new Property("myProp", list);
node.set(prop);
print(node.getType()); // prints PROPERTY
print(node.asProperty().getName()); // prints myProp
It is also possible to build a property node using the overloaded set( ) methods of ModelNode:

node.set("enabled", true);
print(node.getType()); // prints PROPERTY
print(node.toString()); // prints ("enabled" => true)
Types
The value of a node can be one of the enumerations of ModelType:

node.set(ModelType.LIST);
print(node.getType()); // prints TYPE
print(node.toString()); // prints LIST
References
For more information about the Management API, visit https://docs.jboss.org/
author/display/WFLY10/Management+API+reference
Global Operations
Many of these operations should be familiar at this point in the course. Here is a list of the
Management API operations that apply to every management resource:
• read-resource
Reads a management resource's attribute values along with either basic or complete
information about any child resources.
186 JB348-RHJBEAP7-en-6-20170411
The Management API
• read-attribute
Reads the value of an individual attribute.
• write-attribute
Writes the value of an individual attribute.
• read-resource-description
Returns the description of a resource's attributes, types of children, and, optionally, operations.
• read-operation-names
Returns a list of the names of all the operations a particular resource supports.
• read-operation-description
Returns the description of an operation, along with the details of its parameter types and its
return value.
• read-children-types
Returns a list of the types of child resources a particular resource supports.
• read-children-names
Returns a list of the names of all child resources of a given type.
• read-children-resources
Returns information about all of a resource's children that are of a given type. For each child
resource, the returned information is equivalent to executing the read-resource operation
on that resource.
In addition to these global operations, there are a few operations that each resource can expose
(but are not required to expose):
• add
Creates a new resource.
• remove
Removes a resource.
To learn about the required and optional attributes for these operations, use the code completion
feature in CLI.
References
For details about each operation, visit: https://docs.jboss.org/author/
display/WFLY10/Global+operations.
Executing the Management API

There are several ways to execute the Management API:
JB348-RHJBEAP7-en-6-20170411 187
• CLI
• HTTP REST endpoint
• Java
This includes Java-based scripting languages like Groovy, Jython, and Rhino (JavaScript).
Users can make HTTP calls to the HTTP endpoint which by default is on port 9990. The endpoint
is defined in the <management-interfaces> section of the domain controller or standalone
configuration file:
<host name="domain" xmlns="urn:jboss:domain:1.3">

<management>
...
<management-interfaces>
...
<http-interface security-realm="ManagementRealm">
<socket interface="management" port="${jboss.management.http.port:9990}"/>
</http-interface>
...
This HTTP endpoint serves both the Management Console and the Management API:
• Management API
http://172.25.250.254:9990/management
• Management Console
http://172.25.250.254:9990/console
The actual bind address (IP or DNS name) is management by the management <interfaces>
section in the same XML file.
When using the HTTP endpoint, the format of the requests is a little different than when just
using CLI, but the management resource tree is the same:
• Substitute forward slash (/) for the equals sign (=) when separating key/value pairs
• Add the operation at the end of the URL following a question mark (?) with the keyword
operation=. The operations supported with a HTTP GET request are:
◦ resource - equivalent to read-resource (default operation)
◦ attribute - equivalent to read-attribute
requires name argument
◦ resource-description - equivalent to read-resource-description
◦ snapshots - equivalent to list-snapshots
◦ operation-description - equivalent to read-operation-description
requires name argument
◦ operation-names - equivalent to read-operation-names
If an operation is not specified, it defaults to resource.
188 JB348-RHJBEAP7-en-6-20170411
The Management API
• Add any operation arguments as key-value pairs preceded by an ampersand (&) and separated
by the equal sign (=). If the argument is a Boolean (true or false), the presence of the keyword
is enough and means "true."
For example, in the CLI shell the following is used:
/host=Host1/server-config=serverA:read-resource(recursive=true)
For the HTTP endpoint:
http://172.25.250.254:9990/management/host/servera/server-config/serverA?recursive
Insight
The HTTP endpoint is subject to the same security as the Management Console. If the
browser has already authenticated to the web-based console, and the user executes
commands in another tab, authentication is not required again. If starting with a fresh
browser session, EAP asks for the credentials.
The output of such a request looks something like this:
{"auto-start" : true, "group" : "group-station3", "interface" : null,

"jvm" : null, "name" : "serverA", "path" : null,
"socket-binding-group" : null, "socket-binding-port-offset" : 100, "system-property" :
null}
This output is in JavaScript Object Notation, or JSON, format. Many languages have the
capabilities to make HTTP calls like this and process the JSON output.
Users can add a parameter to format the JSON output in "pretty format". Add &json.pretty to
the end of a request to "pretty print" the JSON output:
{
"auto-start" : true,
"group" : "group-station3",
"interface" : null,
"jvm" : null,
"name" : "serverA",
"path" : null,
"socket-binding-group" : null,
"socket-binding-port-offset" : 100,
"system-property" : null
}
Here is a very simple example of a Bash script to print the runtime status of a server:
#!/bin/bash
source scripts.conf
usage(){
echo "Usage:"
echo "serverStatus.sh <host-name> <server-name>"
echo "This script shows the runtime status of an EAP server instance."
echo -e
JB348-RHJBEAP7-en-6-20170411 189
if [ $# -ne 2 ]
then
usage
exit 5
fi
if [ $1 = "-h" ]
then
usage
exit 0
fi
echo `curl --digest -u "$MGMT_USER:$MGMT_PASS" -s \ "http://$DOMAIN_HOST:$MGMT_PORT/

management/host/$1/server-config/$2?read-resource&include-runtime=true" \ | python -c
'import json,sys;obj=json.load(sys.stdin);print obj["status"]'`
In this script, curl is used to send the HTTP REST request and then parse the output with
Python's JSON library. There are many tools available on Windows to do the same thing.
To update management resources, users must use an HTTP PUT request. This requires sending
the request encoded as JSON. This is a much more cumbersome syntax to write. Here is the
curl command to add a new logger to the "full-ha" profile:
curl --digest -s -u admin:jboss "http://172.25.250.254:9990/management" --header

"Content-Type: application/json"
-d '{"operation":"add","level":"DEBUG",
"address":[{"profile":"full-ha"},{"subsystem":"logging"},
{"logger":"org.activemq"}]}'
Here is a recommended approach for creating a template for the JSON syntax:
• Do the command in CLI or in Groovy where the output of the request is in DMR format. In this
case the command entered through the Groovy shell:
groovy:000> result = cli.cmd("/profile=full-ha/subsystem=logging/

logger=org.jboss.as.security:add(level=DEBUG)")
===> org.jboss.as.cli.scriptsupport.CLI$Result@7ced65e0
groovy:000> result.getRequest()
===> {
"address" => [
("profile" => "full-ha"),
("subsystem" => "logging"),
("logger" => "org.jboss.as.security")
],
"operation" => "add",
"level" => "DEBUG"
}
• Convert all the => to colon (:)
• Convert all parentheses to curly braces ({ and })
New Features
New in EAP 7 is the ability to start, stop, and resume batch jobs as well as listing module
dependencies from the management API. The following is an example of using the EAP CLI to
start a batch job:
190 JB348-RHJBEAP7-en-6-20170411
New Features
[standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=batch-jberet:stop-
job(execution-id=2)
A curl command to utilize the management API would like the following:
[standalone@localhost:9990 /] curl --digest -L -D - http://localhost:9990/management \

--header "Content-Type: application/json" -d '{"operation":"stop-job","address":\
[{"deployment":"batch-chunk.war"}. {"subsystem":"batch-jberet"],"execution-
id":"2","json.pretty":1}'
A curl command to view the dependencies of a module, such as io.undertow.core:
[standalone@localhost:9990 /] curl --digest -L -D - http://localhost:9990/management \

--header "Content-Type: application/json" -d '{"operation":"module-info","address":\
[{"core-service":"module-loading"}],"name":"io.undertow.core","json.pretty":1}'
JB348-RHJBEAP7-en-6-20170411 191
Guided Exercise: Exploring the Management

API
In this exercise, you will use the management API to modify the logging level in a standalone
instance.
Resources
Files: /home/student/JB348/labs/management-api
Application URL: localhost:9990
Outcomes
You will be able to use Groovy and curl to manage an EAP standalone instance.
Before you begin

installed in the /opt/ directory and to download the files necessary to interact with the
Management API:
[student@workstation ~]$ lab management-api setup

Run the following command in a terminal window on the workstation to start an EAP
instance using the /home/student/JB348/labs/management-api folder as the base
directory:

-Djboss.server.base.dir=/home/student/JB348/labs/management-api
2. Setup for HTTP Requests

To verify changes made to the managed domain, use curl to issue HTTP API requests.
2.1. Open a terminal window specifically for entering curl commands.
2.2. Practice with the following command. Use it as a model throughout this guided exercise
to verify the changes to the managed domain.
[student@workstation ~]$ curl --digest -u jbossadm:JBoss@RedHat123 -s \

"http://localhost:9990/management"
3. Setup to Explore DMR

Use the Groovy shell to explore DMR objects.
3.1. Open a terminal window specifically for working within the Groovy shell. Change to the
/home/student/JB348/labs/management-api/ directory.
3.2. The security policy allows methods to be executed from the JAR because the jboss-
cli JAR libraries aren't signed. Start Groovy with the following command:
192 JB348-RHJBEAP7-en-6-20170411
[student@workstation ~]$ cd /home/student/JB348/labs/management-api
[student@workstation management-api]$ groovysh -cp \
/opt/jboss-eap-7.0/bin/client/jboss-cli-client.jar \
-Djava.security.manager -Djava.security.policy=security.policy
Insight
Using the shell instead of an IDE makes it simple to test commands.
Additionally, you can record your commands with \r start, saving them for
replay later.
3.3. Enter the following commands, one line at a time, into the Groovy shell.
groovy:000> import org.jboss.as.cli.scriptsupport.*

groovy:000> cli = CLI.newInstance()
groovy:000> cli.connect()
3.4. Enter the following command to get a result object:
groovy:000> result = cli.cmd(":read-resource")

===> org.jboss.as.cli.scriptsupport.CLI$Result@57102fab
groovy:000> node = result.getResponse().get("result")
This command returns a list of the subsystem for the default profile.
4. Modify the Logger with the Management API

Use the curl and Groovy tools to modify a logger.
4.1. Use the following Groovy statements to get a ModelNode:
groovy:000> result = cli.cmd("/subsystem=logging:read-resource(recursive=true)")

groovy:000> node = result.getResponse().get("result")
4.2. Using the information obtained from the previous groovy command, return to the
terminal being used for the curl commands. Write an HTTP API POST request to add a
new logger named org.jboss.as.security at a logging level of DEBUG.
[student@workstation ~]$ curl --digest -s -u jbossadm:JBoss@RedHat123 \

"localhost:9990/management" --header "Content-Type: application/json" \
-d '{"operation":"add","level":"DEBUG","address":[{"subsystem":"logging"},
{"logger":"org.jboss.as.security"}]}'
Note
The values in the -d option must be executed as a single line.
{"outcome" : "success"}
JB348-RHJBEAP7-en-6-20170411 193
4.3. Verify that the new logger has been added by running the following curl command:

"http://localhost:9990/management/subsystem/logging/logger/
org.jboss.as.security?json.pretty"
Insight
When executing the curl, the URL for the management API must be executed
as a single line.
4.4. Use the following commands in Groovy to change the logging level to INFO:
groovy:000> result = cli.cmd("/subsystem=logging/logger=\

org.jboss.as.security:read-resource")
===> org.jboss.as.cli.scriptsupport.CLI$Result@21c71508
groovy:000> node.get("level").set("INFO")
===> "INFO"
groovy:000> node
===> {
"filter" => undefined,
"handlers" => undefined,
"level" => "INFO",
"use-parent-handlers" => true
}
Warning
Modifying the ModelNode object DOES NOT change the management
resource. Only an operation sent to the EAP server can modify a resource.

[student@workstation ~]$ lab management-api grade
workstation.
194 JB348-RHJBEAP7-en-6-20170411
Utilizing the Native Management API
Utilizing the Native Management API
Objectives
After completing this section, students will be able to create custom tools using the native
management API.
The Native Management API

The EAP Management API can be leveraged in several different ways in order to suit the need
of the administrator. This section looks at using the native Java implementation as well as
how to write a Java program using native Java libraries. Up to this point, all interactions with
the API have used a script helper object, CLI. This is a wrapper to make it easy to execute CLI
commands and capture its results in a manner that makes it easy to traverse the sometimes
complex structures returned by the command. This section dives deeper into the API underneath
the CLI object, giving users the finest grain of control over EAP management.
Insight
Users can use compiled Java or any of the JVM-based scripting languages such as
Groovy, Jython, and Rhino, to access the EAP management API.
A management program has several Java library dependencies in order to access the native API.
Java libraries end in .jar. Here are the required client libraries and where to find them:
• jboss-as-controller-client
$JBOSS_HOME/modules/system/layers/base/org/jboss/as/controller-client/
main
• jboss-client
$JBOSS_HOME/bin/client
• jboss-as-protocol
$JBOSS_HOME/modules/system/layers/base/org/jboss/as/protocol/main
• jboss-threads
$JBOSS_HOME/modules/system/layers/base/org/jboss/threads/main
• jboss-dmr
$JBOSS_HOME/modules/org/jboss/dmr/main
This library is called wildfly-controller-client. The library that matches the EAP instance
can be found at $JBOSS_HOME/modules/org/jboss/as/controller-client/main. In
the current configuration for this course, the full name of the library is wildfly-controller-
client-2.1.2.Final-redhat-1.jar.
For example, to declare the dependencies for Groovy:
groovysh -cp wildfly-controller-client-2.1.2.Final-redhat-1.jar:\
JB348-RHJBEAP7-en-6-20170411 195
wildfly-protocol-2.1.2.Final-redhat-1.jar:\
jboss-threads-2.1.1.Final-redhat-1.jar:\
jboss-dmr-1.2.0.Final-redhat-1.jar:\
jboss-client.jar
To use the native API, the native interface must be enabled in the domain and host controllers or
the standalone configuration. Assuming the default port of 9999, for example:
<native-interface interface="management" port="9999"/>
...
The following is a small Groovy program utilizing the native API:
import org.jboss.as.controller.client.*
import org.jboss.dmr.*
client = ModelControllerClient.Factory.create(InetAddress.getByName("172.25.250.254"),
9999)
node = new ModelNode()
node.get("operation").set("read-resource")
result = client.execute(node)
The two import statements at the top of this code sample tells the compiler where to find the
native API objects. The final object, result, is a ModelNode containing the definition of the root
management resource for our course domain in the "result" object:
rootNode = result.get("result")
groovy:000> println(rootNode.get("product-name").asString() + " " +
rootNode.get("product-version").asString())
EAP 7.0.0.GA
Be sure to test the outcome before relying upon the results:
groovy:000> result.get("outcome").asString().equals("success")
===> true
Always close resources when they are no longer needed:
client.close()
Security is important when using the native management interface, so most EAP developers
use authentication during the onnection process. The management API reference linked below
provides an example for authenticating.
The following is another example of using the native API from a CLI command. In CLI, a user can
write:
/profile=production/subsystem=threads/bounded-queue-thread-pool=pool1:write-
attribute(name=count,value=20)
The equivalent using the native API in compiled Java:
ModelControllerClient client =
196 JB348-RHJBEAP7-en-6-20170411
The Native Management API
ModelControllerClient.Factory.create(InetAddress.getByName("172.25.XX.9"), 9999);
ModelNode op = new ModelNode();

op.get("operation").set("write-attribute");
ModelNode addr = op.get("address");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("name").set("count");
op.get("value").set(20);
ModelNode result = client.execute(op);
The essentials of the native API:
• Create a connection to the native interface, receiving a ModelControllerClient
• Build an OBJECT type ModelNode containing the "operation", "address", and any attributes
required by the operation.
• Use the client to execute the operation, passing in the ModelNode to define what operation to
use.
• Examine the result ModelNode received from the execution of the operation for success or
failure.
Other features of the native API:
• Use of operation headers to control how the operation executes
• Composite operations that execute as a unit
• Define a roll-out plan to details how the configuration change is to be applied to the servers in
the domain
• Asynchronous execution of operations, with executions running in the background
References
The native Management API is documented in more detail at https://
docs.jboss.org/author/display/WFLY10/The+native+management+API.
This documentation includes the Maven dependency names for the required client
libraries.
JB348-RHJBEAP7-en-6-20170411 197
Quiz: Native Management API
1. Which four languages can you use to write program that access the native interface?
(Choose four.)
a. Java
b. Rhino
c. Perl
d. Python
e. Jython
f. Groovy
2. Which interface must be enabled in order to use the native API?
a. Native Management
b. Internal
c. Standalone
d. Https-Interface
3. Which object in the API is used to execute an operation?
a. NodeClient
b. cli.connect()
c. cli.execute()
d. ModelNode
e. ModelControllerClient
4. When a client's execute() method is called, which object is returned?
a. NodeClient
b. ModelControllerClient
c. ModelNode
d. Node
5. Which method should be executed to free up the connection to the native management
interface?
a. exit()
b. close()
c. collect()
d. trash()
198 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
1. Which four languages can you use to write program that access the native interface?
(Choose four.)
a. Java
b. Rhino
c. Perl
d. Python
e. Jython
f. Groovy
2. Which interface must be enabled in order to use the native API?
a. Native Management
b. Internal
c. Standalone
d. Https-Interface
3. Which object in the API is used to execute an operation?
a. NodeClient
b. cli.connect()
c. cli.execute()
d. ModelNode
e. ModelControllerClient
4. When a client's execute() method is called, which object is returned?
a. NodeClient
b. ModelControllerClient
c. ModelNode
d. Node
5. Which method should be executed to free up the connection to the native management
interface?
a. exit()
b. close()
c. collect()
d. trash()
JB348-RHJBEAP7-en-6-20170411 199
Configuring Custom Services with JMX
Objectives
After completing this section, students will be able to monitor EAP using JMX.
JMX
Java Management Extensions (JMX) provides a means of managing and monitoring resources in
the Java Virtual Machine (JVM). Monitoring resource consumption and other low-level aspects
of the JVM provides useful insight to the configuration of the EAP server or with the application
itself, to detect issues such as memory leaks. JMX was developed through the Java Community
Process (JCP) and is based on two Java Specification Requests (JSR):
• JSR 3 - the base JMX specification
• JSR 160 - JMX Remote API
This discussion of JMX revolves around its application with JBoss EAP, however, JMX technology
has uses in any application that runs in a Java Virtual Machine.
Managed Beans
An EAP resource that can be managed or monitored is instrumented by one or more Managed
Beans (MBeans). EAP provides an MBean server that manages all the MBeans. When an MBean
is registered with the server, it is made available for access inside and outside of the application
server. JMX provides connectors that allow MBeans to be accessed remotely.
MBeans are flexible and easy to implement. Existing resources may be easily retrofitted with
MBeans to allow for their management and monitoring. All MBeans follow a particular design
pattern for its data attributes and interfaces.
An MBean has a management interface consisting of:

• Notifications
• Data attributes that can be read and optionally written
• Operations that can be invoked
MBeans can be standard or dynamic. A standard MBean defines its interface at compile time.
A dynamic MBean defines its interface at runtime. The following is a sample standard MBean
interface:
package com.redhat.jb348;
import javax.management.MXBean;
@MXBean
public interface HelloMBean {
public String sayHello();
public void setName(String name);

public String getName();
}
200 JB348-RHJBEAP7-en-6-20170411
Managed Beans
This MBean will have one attribute, "name", and one operation, "sayHello". The attribute is
read/write because there is a set and get method for the attribute.
Creating an implementation of this MBean in JEE is easy. Create tje service as an EJB Singleton
with the @Singleton annotation:
@Singleton
@Startup
public class HelloService implements HelloMBean {
private String name = "Somebody";
...
public String sayHello() {
return "Hello, " + name;
}
public void setName(String name) {

this.name = name;
}
public String getName() {

return name;
}
...
Before building the JAR, some additional code is required so that the MBean can register and
unregister itself. To do this, use the annotations PostConstruct and PreDestroy:
@Singleton
@Startup
public class HelloService implements HelloMBean {
private String name = "Somebody";

private ObjectName serviceName;
private MBeanServer mbeanServer;
...
@PostConstruct
public void start() throws Exception {
serviceName = new ObjectName("com.redhat.jb348:service=HelloService");
mbeanServer = ManagementFactory.getPlatformMBeanServer();
mbeanServer.registerMBean(this, serviceName);
}
@PreDestroy
public void stop() throws Exception {
mbeanServer.unregisterMBean(serviceName);
}
The container creates this singleton when the application is deployed with the @Startup
annotation. After creating the EJB, it invokes the start( ) method because it is
annotated with @PostConstruct. The logic in this method registers the bean by the name
"com.redhat.jb348:service=HelloService". When the application is undeployed, the stop( )
method is called because it is annotated with @PreDestroy.
JB348-RHJBEAP7-en-6-20170411 201
Users build and deploy the JAR like any other application and the MBean will be ready to lookup,
set its attributes, and invoke its operations.
Remote JMX Scripting

Users can connect to both local or remote applications using either the standard JMX protocol or
a custom one.
The following script, jmx.groovy, reads the number of active sessions from a deployment of
version.war:
import javax.management.*
import javax.management.remote.*
url = new JMXServiceURL("service:jmx:remoting-jmx://localhost:9999")

jmxconn = JMXConnectorFactory.connect(url, null)
server = jmxconn.getMBeanServerConnection()
resource = new ObjectName("jboss.as:deployment=version.war,subsystem=web")
sessions = server.getAttribute(resource, "activeSessions")
println("The version application has " + sessions + " active sessions")
jmxconn.close()
Since JMX is built into the Java VM, only one dependency is needed: jboss-client.jar.
groovy -cp jboss-client.jar jmx.groovy
JConsole
JConsole is a useful GUI tool for monitoring the Java Virtual Machine's memory, consumption,
and other useful information for system administrators. Users connect to JConsole via either a
remote or local JMX connection. In the case of EAP 7, the protocol remote+http allows users to
bridge the HTTP and jboss-remoting protocols with the same port.
To simplify connecting an instance of EAP 7 to JConsole, EAP 7 provides a convenient script that
makes the CLI as well as remote+http JMX protocol available. Run the following command from
the ${JBOSS_HOME}/bin directory:
[student@workstation bin]$ ./jconsole.sh
After running the command, users will be prompted to enter the connection URL to connect to
the Java VM. The syntax to use the remote+http protocol is as follows:
service:jmx:remote+http://<host-name>:<port>
For example, to connect to a default standalone instance of EAP running on localhost, use the
following connection URL:
service:jmx:remote+http://localhost:9990
Connecting to a remote instance or domain mode is the same process, except administrators
should connect to the domain controller.
Ensure a management user has already been created, and provide the credentials for the user in
the GUI prompt before connecting.
202 JB348-RHJBEAP7-en-6-20170411
JConsole
Once connected to the JVM, users are provided with an overview for monitoring the memory
usage, threads, classes, and CPU usage. Clicking a tab at the top of the screen provides a more
detailed graph as well as further information pertaining to the specific topic. For example, the
Memory tab provides information about memory consumption and garbage collection statistics.
Using the Memory screen, administrators can detect whether an application is inefficiently
using or leaking memory. Further, JConsole provides users with the ability to access registered
MBeans. From the MBeans tab, users can manipulate values and call methods in order to
facilitate application management.
JB348-RHJBEAP7-en-6-20170411 203
Guided Exercise: Custom Services with JMX
In this exercise, you will use JConsole to connect to a cluster.
Resources
Files: /home/student/JB348/apps/airportsv2.war
Application URL: http://172.25.250.10:8080/airports
Outcomes
You will be able to use JConsole to connect to an EAP managed domain.
Before you begin

Use the following command in the workstation VM to verify that the managed domain from
the lab Configuring a JBoss EAP Cluster is configured, and to download the necessary files for
the guided exercise:
[student@workstation ~]$ lab custom-jmx setup

1.1. Run the following command in a terminal window on the workstation to start the
domain controller:

host controller on Server A:

host controller on Server B:

204 JB348-RHJBEAP7-en-6-20170411
2. Start JConsole
2.1. In a new terminal window on workstation, navigate to the /opt/jboss-eap-7.0/
bin directory.
2.2. Use the following command to start JConsole and open the application's GUI:
2.3. In the New Connection window, select Remote Process. In the text box, enter the
following as the remote connection URL:
service:jmx:remote+http://172.25.250.254:9990
2.4. Below the Remote Process heading, enter the following credentials:
2.5. Click Connect
3. Explore JConsole
3.1. In the JConsole GUI, take a moment to click through the different tabs, including the
Overview, Memory, Threads, and VM Summary.
3.2. In the Overview tab, adjust the Time Range to 1 min for quicker feedback about the
JVM status.
4. Deploy the Airports V2 Application

A new and supposedly improved version of the Airports application is ready for deployment.
Deploy the application and then use JConsole to monitor the memory consumption.
domain controller:

4.2. The CLI Shell provides the deploy command to deploy an application. Deploy the
airportsv2.war application into both server groups:
[domain@172.25.250.254:9990 /] deploy /home/student/JB348/apps/airportsv2.war \

--server-groups=Group1
Note
The deployment can fail due to an Infinispan timeout. If this happens, run the
JB348-RHJBEAP7-en-6-20170411 205
4.3. Verify that the application deployed correctly by visiting

http://172.25.250.10:8080/airports to see the Airport application.
5. Monitor the Load

Use JConsole to monitor the memory usage of the Airports application. Because this service
is meant to be used in high frequency, being efficient and maintaining a low footprint is the
highest priority.
5.1. In the Airports application, enter KRDU as an airport code and then click Load airport.
5.2. Observe the changes to the graphs in the overview of JConsole.
5.3. Continue to press Load airport several dozen times, quickly, and watch the memory
escalate.
5.4. A healthy Java application should be doing a good of job garbage collection for items
that are no longer in use, however this updated version of the Airports application is
occupying a lot of memory without garbage collecting.
5.5. Click the Memory tab in JConsole and then click Perform GC to manually perform a
garbage collection. Notice that the memory usage declines. Based on the JConsole JVM
reports, the application is leaking memory and the latest update should be rolled back
until the issue is resolved.

[student@workstation ~]$ lab custom-jmx grade
6.2. Press Ctrl+C in the terminal windows where you started the domain controller, host
controllers, and JConsole on the workstation.
206 JB348-RHJBEAP7-en-6-20170411
Lab: Monitoring and Management
Lab: Monitoring and Management
In this lab, you will use the management API to create a new server group and new servers, and
then use JConsole to monitor the JVM.
Resources
Files: /home/student/apps/version.war
Application URL: http://172.25.250.10:8230/version,
http://172.25.250.11:8230/version
Outcomes
You will be able to use the management API to create a new server group, and monitor an
application with JConsole.
Before you begin

Use the following command on workstation to configure a managed domain and download the
application:
[student@workstation ~]$ lab monitoring-lab setup
The version.war application is read for some staging testing. In order to get the preliminary
testing started, you are tasked with creating a new server group with two new servers using the
management API. This group will serve as the staging group intended to replicate the production
environment. After deploying the application, use JConsole to monitor the JVM.

domain controller:



JB348-RHJBEAP7-en-6-20170411 207
2. Use the curl commands and format an HTTP API POST request to add a new server group
named production-group using the ha profile.
3. Add two new servers to the new server group, production-group, using curl and
the management API. Update the script located at /home/student/JB348/labs/
monitoring-lab/create-servers.sh replacing the items in brackets using the
following properties for the servers:
• Server One:
◦ Host: servera
◦ Name: prod-one
◦ Port offset: 150
• Server Two:
◦ Host: serverb
◦ Name: prod-two
4. Execute the completed /home/student/JB348/labs/monitoring-lab/create-

servers.sh script to create the servers.
5. Verify that the new servers have been added by running a curl command to the
management API on each host.
6. Using the EAP CLI, start the new servers and then deploy the version.war application to
the production-group server group.
7. Verify that the application is running by accessing the application on both servers from the
production-group server group.
Use a web browser to navigate to http://172.25.250.10:8230/version and

http://172.25.250.11:8230/version.
8. Connect JConsole to the EAP JVM running on the domain. Monitor the JVM while
interacting with the application.

208 JB348-RHJBEAP7-en-6-20170411
[student@workstation ~]$ lab monitoring-lab grade
JB348-RHJBEAP7-en-6-20170411 209
Solution
In this lab, you will use the management API to create a new server group and new servers, and
then use JConsole to monitor the JVM.
Resources
Files: /home/student/apps/version.war
Application URL: http://172.25.250.10:8230/version,
http://172.25.250.11:8230/version
Outcomes
You will be able to use the management API to create a new server group, and monitor an
application with JConsole.
Before you begin

application:
[student@workstation ~]$ lab monitoring-lab setup
The version.war application is read for some staging testing. In order to get the preliminary
testing started, you are tasked with creating a new server group with two new servers using the
management API. This group will serve as the staging group intended to replicate the production
environment. After deploying the application, use JConsole to monitor the JVM.

domain controller:



210 JB348-RHJBEAP7-en-6-20170411
Solution
2. Use the curl commands and format an HTTP API POST request to add a new server group
named production-group using the ha profile.

"172.25.250.254:9990/management" --header "Content-Type: application/json" \
-d '{"operation":"add","profile":"ha", "socket-binding-group":"ha-sockets",
"address":[{"server-group":"production-group"}]}'
{"outcome" : "success"}
3. Add two new servers to the new server group, production-group, using curl and
the management API. Update the script located at /home/student/JB348/labs/
monitoring-lab/create-servers.sh replacing the items in brackets using the
following properties for the servers:
• Server One:
◦ Host: servera
◦ Name: prod-one
• Server Two:
◦ Host: serverb
◦ Name: prod-two
The completed script should look like the following:
#!/bin/bash
curl --digest -s -u jbossadm:JBoss@RedHat123 "172.25.250.254:9990/management" --

header "Content-Type: application/json" -d '{"operation":"add","group":"production-
group", "auto-start":"true","socket-binding-port-offset":"150", "address":
[{"host":"servera"},{"server-config":"prod-one"}]}'
curl --digest -s -u jbossadm:JBoss@RedHat123 "172.25.250.254:9990/management" --

header "Content-Type: application/json" -d '{"operation":"add","group":"production-
group", "auto-start":"true","socket-binding-port-offset":"150", "address":
[{"host":"serverb"},{"server-config":"prod-two"}]}'
JB348-RHJBEAP7-en-6-20170411 211
4. Execute the completed /home/student/JB348/labs/monitoring-lab/create-

servers.sh script to create the servers.
[student@workstation ~]$ cd /home/student/JB348/labs/monitoring-lab

[student@workstation monitoring-lab]$ ./create-servers.sh
5. Verify that the new servers have been added by running a curl command to the
management API on each host.

"http://172.25.250.254:9990/management/host/servera?json.pretty"

"http://172.25.250.254:9990/management/host/serverb?json.pretty"
6. Using the EAP CLI, start the new servers and then deploy the version.war application to
the production-group server group.

[student@workstation ~]$ ./jboss-cli.sh -c --controller=172.25.250.254:9990
[domain@172.25.250.254:9990 /] /host=servera/server-config=prod-one\
[domain@172.25.250.254:9990 /] /host=serverb/server-config=prod-two\
[domain@172.25.250.254:9990 /] deploy \
/home/student/JB348/apps/version.war \
--server-groups=production-group
7. Verify that the application is running by accessing the application on both servers from the
production-group server group.
Use a web browser to navigate to http://172.25.250.10:8230/version and

http://172.25.250.11:8230/version.
8. Connect JConsole to the EAP JVM running on the domain. Monitor the JVM while
interacting with the application.
Start JConsole by running the following command:

In the New Connection window, select Remote Process. In the text box, enter the following
as the remote connection URL:
service:jmx:remote+http://172.25.250.254:9990
Below the Remote Process, enter the following credentials:

212 JB348-RHJBEAP7-en-6-20170411
Solution

[student@workstation ~]$ lab monitoring-lab grade
JB348-RHJBEAP7-en-6-20170411 213
Summary
• The management console provides the ability to clone profiles when running in a managed
domain.
• The exposed Management API is useful for creating custom tools for managing and monitoring
EAP.
• When invoking CLI operations with the Management API, a value is returned as an object type
of ModelNode.
• A new feature of EAP 7 is the ability to manage batch jobs and to list module dependencies
using the management API.
• The HTTP endpoint for the management API is that same as the Management Console, but use
the context management instead of console.
• The native management API provides the most detaied control over EAP management by
enabling users to create custom applications that interact with EAP management.
• JMX provides a means of managing and monitoring resources based on JSR-3 and JSR-160.
• MBeans are classes that can monitor EAP resources and are accessible remotely via JMX.
• JConsole is a graphical interface monitoring tool that connects to local or remote Java Virtual
Machines through JMX.
214 JB348-RHJBEAP7-en-6-20170411
TRAINING
CHAPTER 7
CONFIGURING AND TUNING THE

MESSAGING SYSTEM
Overview
Goal Given a properly configured JBoss EAP instance, manage a
built in message system.
Objectives • Describe the Artemis architecture and subsystem.
• Configure Artemis Persistence.
• Configure bridges.
• Manage ActiveMQ Artemis for high availability.
• Tune the messaging system for optimal performance.

Sections • Configuring the Features of ActiveMQ Artemis (and Guided
Exercise)
• Configuring Message Persistence with ActiveMQ

Artemis(and Guided Exercise)
• Configuring Messaging Bridges (and Guided Exercise)
• Configuring Messaging Cluster for High Availability (and

Demo)
• Tuning Messaging Performance (and Guided Exercise)

Lab • Messaging System Configuration and Tuning
JB348-RHJBEAP7-en-6-20170411 215
Chapter 7. Configuring and Tuning the Messaging System
Configuring the Features of ActiveMQ Artemis
Objectives
After completing this section, students should be able to describe the Artemis architecture and
subsystem.
Architecture
Message Oriented Middleware, or MOM, are software systems that receive, store, and transmit
structured data between application programs in a loosely coupled manner. One program can
generate 10 messages and the MOM stores them, generally speaking, until another program
comes along and retrieves them. The structure and content of the message is determined solely
by the messaging client that sends the message. An example of the message could be a stock
quote. In this example, the message contains the stock symbol, current bid, number of units bid,
and so on.
All MOM support at least two messaging patterns:
• Point to Point: A message is sent by one client and picked up by one and only one
receiving client.
• Publish and Subscribe: A message is sent once and picked up by several receiving
clients who hold a subscription to that set of messages.
A queue is the MOM construct that supports the point-to-point messaging pattern. Typically,
once a message is retrieved from the queue it is removed and no other client can read it. In the
diagram, a client sends a message, the message is held in a queue, and a second client removes
the message from the queue. Note the ability for the messages to be held in a data store.
A topic is the MOM construct that supports the publish-subscribe messaging pattern. A
message is sent labeled with a subject. One or more subscribers subscribe to this topic,
optionally filtering by subject. As the below diagram depicts, each subscriber has a virtual copy
of the messages. The real messages are not deleted from the system until all subscribers have
retrieved them. Some MOM create a queue for each subscriber and duplicates the messages to
support topic functionality.
216 JB348-RHJBEAP7-en-6-20170411
Architecture
The ActiveMQ Artemis is the MOM provided by JBoss EAP 7 replacing the HornetQ from
JBoss EAP 6. Despite the change, most of the configurations from HornetQ are supported by
ActiveMQ Artemis. Use the JBoss Server Migration Tool to migrate the configuration. Here is a
diagram depicting the architecture and features of ActiveMQ Artemis.
In this diagram, three clusters of 12 ActiveMQ Artemis instances (EAP instances) are available.
On each cluster instance, there are clients sending messages into queues and clients receiving
messages from the queues. Notice that one of the inbound and one of the outbound connections
is communicating over SSL, an optional feature. The "sheriff badge" denotes that the server can
enforce access to ActiveMQ Artemis resources, by role. The contents of the messages can be
saved to a journal (the barrel). This requires the libaio module, only available on Linux, to write
asynchronously to the journal for higher throughput.
A router box symbol is available on one of the corners of the three clustered instances. This
symbolizes bridging between ActiveMQ Artemis instances. Bridges can be local within the same
network or reach across WANs. Bridges can be unidirectional or bidirectional.
JB348-RHJBEAP7-en-6-20170411 217
ActiveMQ Connectors and Acceptors

For the remainder of this book, the EAP 7 embedded ActiveMQ Artemis is referred to as
ActiveMQ. Its network configuration is based on two components:
• Acceptors define networking protocols and parameters for accepting connections from
messaging clients.
• Connectors define networking protocols and parameters for connecting to ActiveMQ servers.
Note
Note that ActiveMQ uses the term connector to refer to a client-side component,
while other EAP subsystems usually refer to a server-side component when using this
term.
Because EAP 7 acts as both a server and a client for ActiveMQ, the default EAP 7 configuration
files includes ready-to-use definitions for both component types. Two kinds of ActiveMQ
acceptors and connectors are provided:
• http: uses the native ActiveMQ protocol tunneled through an HTTP connection. The HTTP
connection is accepted by the undertow subsystem. This way an EAP 7 server instance does
NOT require opening additional firewall ports to accept connections from remote messaging
clients.
• in-vm: allows messaging clients running under the same JVM as the ActiveMQ server to
connect without networking overhead.
Networking parameters for an ActiveMQ connector are defined indirectly, by referring to an

acceptor element. The connector connects to whatever IP address and TCP port the acceptor is
configured to accept connections from. This indirection is related to the way ActiveMQ remote
clients use a discovery mechanism to find servers to connect to. The following listing shows the
connectors and acceptors in the default EAP 7 configuration files:
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
...
<http-connector name="http-connector" socket-binding="http"
endpoint="http-acceptor" />
....
<http-acceptor name="http-acceptor" http-listener="default" />

....
...
</server>
</subsystem>
Callouts in the previous listing highlight the relationship between connectors and acceptors:
The <http-connector> element named http-connector references the <http-

acceptor> element named http-acceptor by using the endpoint attribute.
The <in-vm-connector> element does not need to reference any <in-vm-acceptor>
element because local clients do NOT need discovery to find the messaging server.
218 JB348-RHJBEAP7-en-6-20170411
Overview of the Messaging Subsystem Configuration
The <http-acceptor> element references the http-listener named default, which

is defined by the undertow subsystem.
A third connector and acceptor type is supported by EAP 7: the remote type. It allows remote
clients to connect to the messaging server using the ActiveMQ native protocol instead of HTTP
tunneling. The native protocol is required by remote clients running outside an EAP 7 server and
also to connect to standalone ActiveMQ servers.
Creating a new <remote-connector> and <remote-acceptor> pair on EAP 7 also requires

creating a new <socket-binding> to provide the IP address and TCP port to be used by the
<remote-acceptor>. For more information refer to the EAP product documentation.
The remote connector and acceptor type also supports connections to EAP 6 and standalone
HornetQ servers but additional configurations are required. Refer to the EAP 7 product
documentation for details.
Overview of the Messaging Subsystem Configuration

The messaging technology in EAP 7 is configured in the messaging-activemq subsystem. This
subsystem is included when starting the server with the full or full-ha configuration. The
full-ha provides advanced configuration like clustering and high availability.
To view all available settings in the messaging-activemq subsystem, use the following CLI
operation:
/subsystem=messaging-activemq:read-resource-description(recursive=true)
The configuration for the messaging-activemq subsystem is contained within the

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> element:
<cluster password="${jboss.messaging.cluster.password:CHANGE ME!!}"/>
<role name="guest" send="true" consume="true" create-non-durable-
queue="true" delete-non-durable-queue="true"/>
</security-setting>
<address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-
address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152"
message-counter-history-day-limit="10" redistribution-delay="1000"/>
<http-connector name="http-connector" socket-binding="http" endpoint="http-
acceptor"/>
<http-connector name="http-connector-throughput" socket-binding="http"
endpoint="http-acceptor-throughput">
</http-connector>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="direct-deliver" value="false"/>
</http-acceptor>
<broadcast-group name="bg-group1" connectors="http-connector" jgroups-
channel="activemq-cluster"/>
<discovery-group name="dg-group1" jgroups-channel="activemq-cluster"/>
<cluster-connection name="my-cluster" address="jms" connector-name="http-
connector" discovery-group="dg-group1"/>
JB348-RHJBEAP7-en-6-20170411 219
<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>

<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
<connection-factory name="InVmConnectionFactory" connectors="in-vm"
entries="java:/ConnectionFactory"/>
<connection-factory name="RemoteConnectionFactory" ha="true" block-
on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector"
entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
<pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-
vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
</server>
</subsystem>
Message Expiration
Like many MOM, ActiveMQ supports the concepts of expiration. Messages can be set with a time
to live when created. A message will not be delivered from its original queue once it has expired.
However, an expiry address can be specified and the expired message will be sent to that address
and deleted from its original queue. More than one queue can be bound to an expiry address. An
expiry address is set as follows:
...
<address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-
address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152"
message-counter-history-day-limit="10"/>
...
<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
...
</server>
</subsystem>
In the above example, all queues are defined to have the same expiry queue because of the hash
# wildcard.
A <jms-queue> for the expiry queue, like all other queues, must be defined. In this example, the
queue name attribute is ExpiryQueue. Observe that the jms.queue part must be left off.
A reaper thread running in the ActiveMQ server periodically inspects the queues checking for
expired messages. You can control this thread through two configurations:
• message-expiry-scan-period: In milliseconds, how often the queues are scanned for

expired messages. Default is 30000ms (30 seconds). Set this value to -1 to disable the reaper
thread.
<message-expiry scan-period="30000"/>
...
</server>
</subsystem>
• message-expiry-thread-priority: A number between 0 and 9 representing the reaper

thread priority with 9 being the highest. Default is 3.
220 JB348-RHJBEAP7-en-6-20170411
Message Redelivery
<message-expiry thread-priority="3" scan-period="30000"/>
...
</server>
</subsystem>
Message Redelivery
If a message is never successfully taken off the queue, due to a transaction rollback or failure to
acknowledge the message, it goes back to the queue. It could go back to the queue many times,
which clogs up the queue. ActiveMQ has two ways to deal with undelivered messages:
• Delayed redelivery: To reduce overload on the network or CPU resources, the

administrator can configure a redelivery delay interval for a queue or queues with the
<address-setting> configuration. The interval is given in milliseconds.
<address-setting name="#" message-counter-history-day-limit="10" page-size-

bytes="2097152" max-size-bytes="10485760" redelivery-delay="30000" expiry-
address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
The default value is 0 (no delay).
• Dead letter address: A fixed number of redelivery attempts can be configured. After
the number of delivery attempts fails, the message is moved to the dead letter queue assigned
for the queue.
<address-setting name="#" message-counter-history-day-limit="10" page-

size-bytes="2097152" max-size-bytes="10485760" max-delivery-attempts="30"
redelivery-delay="555" expiry-address="jms.queue.ExpiryQueue" dead-letter-
address="jms.queue.DLQ"/>
Use the following CLI operation to change the number of redelivery attempts:
/subsystem=messaging-activemq/server=default/address-setting=#:write-
attribute(name=max-delivery-attempts, value=30)
The default setting for max delivery attempts is 10. A setting of -1 will cause infinite delivery
attempts. If no dead letter queue is defined, the message is discarded.
Both of these options can be combined.
Configuration Syntax
The CLI shell can be used to configure the ActiveMQ subsystem. Here are some configuration
examples:
Create a new queue

To create a new queue, use the following CLI command:
jms-queue add --queue-address=jms.queue.example --entries=java:/jms/queue/ExampleQueue
Change Expiry Scan Period

To change the expiry scan period to one minute, use the following CLI operation:
JB348-RHJBEAP7-en-6-20170411 221
/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-scan-
period,value=60000)
Change Expiry Thread Priority

To change the expiry thread priority, use the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-thread-
priority, value=6)
Change Redelivery Delay Interval

To change the redelivery delay interval for all queues, use the following CLI operation:
attribute(name=redelivery-delay, value=30000)
If the redelivery delay must be configured for a specific queue, first create a new address setting
with the name of the queue:
/subsystem=messaging-activemq/server=default/address-setting=jms.queue.example:add()
After, change the redelivery delay interval:
/subsystem=messaging-activemq/server=default/address-setting=jms.queue.example:write-
attribute(name=redelivery-delay, value=30000)
Change the Number of Redelivery Attempts

To change the number of redelivery attempts for all queues, use the following CLI operation:
/subsystem=messaging-activemq/server=default/address-setting=#:write-attribute(name=max-
delivery-attempts, value=20)
To specify a specific queue, use the address setting defined for the queue:
/subsystem=messaging-activemq/server=default/address-setting=jms.queue.example:write-
attribute(name=max-delivery-attempts, value=20)
Monitoring Queues
To check the number of messages from a specific queue that are waiting to be consumed, use
the following CLI operation:
/subsystem=messaging-activemq/server=default/jms-queue=jms.queue.example:read-
attribute(name=message-count)
To list the messages from a specific queue that are waiting to be consumed, use the list-
messages operation:
/subsystem=messaging-activemq/server=default/jms-queue=jms.queue.example:list-messages
222 JB348-RHJBEAP7-en-6-20170411
Configuration Syntax
References
For more information, visit the Configuring Messaging section of the
EAP 7 documentation
platform/
JB348-RHJBEAP7-en-6-20170411 223
Guided Exercise: Configuring the Features of

ActiveMQ Artemis
In this exercise, you will explore the ActiveMQ Artemis features like creating a new queue,
configuring an expiry queue, and configuring a dead letter queue.
Resources
Files: /home/student/JB348/labs/exploring-artemis
Outcomes
You will be able to manage the ActiveMQ Artemis subsystem.
Before you begin

Use the following command in the workstation VM to set up a standalone server, open the
firewall ports, and to download the messaging client application:
[student@workstation ~]$ lab exploring-artemis setup
1. Start the Standalone Server

The set up script for this guided exercise downloaded files for an preconfigured standalone
server.
Open a new terminal window from workstation and run the following command to start
the standalone server:

-Djboss.server.base.dir=/home/student/JB348/labs/exploring-artemis/machine1/
2. Create a New Queue

The development team has created a new application that requires the use of the messaging
technology. Create a new queue with the following characteristics:
• Queue Name: ProjectQueue
• JNDI Name: java:/jboss/exported/jms/queue/ProjectQueue
• Persistence: No
• Remote client access: Yes
2.1. Open a new terminal window from the workstation VM and connect to CLI to create
the queue:

2.2. Create the queue with the specified characteristics:
224 JB348-RHJBEAP7-en-6-20170411
[standalone@172.25.250.254:9990 /] jms-queue add \
--queue-address=ProjectQueue --durable=false \
--entries=java:/jboss/exported/jms/queue/ProjectQueue
Important
This queue is intended to be accessible by external clients. Queues that are
accessible by external clients must start their JNDI name with java:/jboss/
exported.
3. Test the New Queue

3.1. By default, the queue can be accessed by a remote client only if a valid credential is
provided. Open a new terminal window and create a new credential with the following
characteristics:
• Type of user: Application User
• Username: jms-client
• Group: guest
• The credential does not connect as a remote service.

[student@workstation bin]$ ./add-user.sh -sc /home/student/JB348/\
labs/exploring-artemis/machine1/configuration/
Note
Users that belong to the guest group can send, consume, create, and delete
non-durable queues.
3.2. The message-client.jar application is a client for testing the messaging queue. Run
the application, passing the send argument with the credentials created in the previous
step. This sends one message to the ProjectQueue queue . The expected output is:
"Message sent". If there are errors, fix them until the success message is visible.
[student@workstation bin]$ cd /home/student/JB348/apps

[student@workstation apps]$ java -jar messaging-client.jar \
send --user=jms-client --password=JBoss@RedHat123
3.3. Run the application again, passing the receive argument. This takes one message off
the ProjectQueue queue. The output should report a message with the text "hello".
If there are errors, fix them until the example reports success.
JB348-RHJBEAP7-en-6-20170411 225

receive --user=jms-client --password=JBoss@RedHat123
3.4. Run the application again with the receive argument. This time, the output should
report a message with the text "No messages on queue".
4. Define the Expiry Queue

Update the messaging system so that a message on the ProjectQueue is redirected to
another queue if it is not consumed within one second. Configure a new expiry queue that
receives expired messages with the following characteristics:
• Queue Name: ProjectQueueEXQ
• JNDI Name: java:/jboss/exported/jms/queue/ProjectQueueEXQ
• Persistence: No
4.1. Return to the terminal that is running CLI and create the queue with the specified
characteristics:

--queue-address=ProjectQueueEXQ --durable=false \
--entries=java:/jboss/exported/jms/queue/ProjectQueueEXQ
4.2. Configure a new address settings to redirect expired messages:
[standalone@172.25.250.254:9990 /] /subsystem=messaging-activemq/server=default/
\
address-setting=jms.queue.ProjectQueue\
:add(expiry-address=jms.queue.ProjectQueueEXQ,expiry-delay=1000)
Note
Internally, ActiveMQ Artemis adds jms.queue to each queue name when it is
referred to outside of the JMS configuration elements.
5. Test Message Expiration

Place a message on the queue with its time to live set to 1 second. The messaging client
waits three seconds after sending the message and tries to retrieve it. The message should
be gone because it has expired. The application then verifies the message is on the expiry
queue. Run the following command to test the expiration:

expiry --user=jms-client --password=JBoss@RedHat123
You will see the following output:
...
Test message found on the expiry queue as expected
226 JB348-RHJBEAP7-en-6-20170411
...
6. Define the Dead Letter Queue

Update the messaging subsystem so that message delivery is limited to two times. After two
attempts, the message should be redirected to another queue. Configure a new DLQ queue
that receives expired messages from the ProjectQueue with the following characteristics:
• Queue Name: ProjectQueueDLQ
• JNDI Name: java:/jboss/exported/jms/queue/ProjectQueueDLQ
• Persistence: No
characteristics:

--queue-address=ProjectQueueDLQ --durable=false \
--entries=java:/jboss/exported/jms/queue/ProjectQueueDLQ
6.2. Configure the existing address settings to redirect DLQ messages:
\
:write-attribute(name=dead-letter-address, value=jms.queue.ProjectQueueDLQ)
\
:write-attribute(name=max-delivery-attempts, value=2)
7. Test Message Redelivery Failure

On the messaging client, the command delivery puts a message on the ProjectQueue
queue. It then attempts to consume the message within a transaction. During the
transaction, the transaction is aborted so that the message does not get acknowledged
(taken off the queue). The messaging subsystem tries to retrieve the message three times.
After the third time, the message is forwarded to the dead letter queue.
Run the following command to test the redelivery failure:

delivery --user=jms-client --password=JBoss@RedHat123
The expected output is:
Message went to DLQ as expected

Original queue: jms.queue.ProjectQueue
JB348-RHJBEAP7-en-6-20170411 227

8.1. Run the following command to verify that the messaging subsystem was correctly
configured:
[student@workstation apps]$ lab exploring-artemis grade
8.2. Press Ctrl+C in the terminal windows where you started the instance of EAP 7 to stop
the server.
228 JB348-RHJBEAP7-en-6-20170411
Configuring Message Persistence with ActiveMQ Artemis
Configuring Message Persistence with

ActiveMQ Artemis
Objectives
After completing this section, students should be able to configure message persistence in
Artemis.
Message Persistence
ActiveMQ offers the ability to run in memory-only mode, where no messages are persisted to
disk. This option is valid if messages are highly transient, such as stock quoting. However, it is
more likely that messages should survive a server shutdown or failure. The default ActiveMQ
configuration in JBoss EAP 7 is to enable persistence using asynchronous I/O if available. By
default, queues and topics are persisted. The persistence could be disabled with the following CLI
operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=persistence-
enabled,value=false)
Important
For a message to be persisted, there are three requirements:
• The message must be marked as durable.
• The queue or topic must be durable.
• Persistence must be enabled in ActiveMQ.
Comparing Java NIO and Linux AIO

Java new I/O, or NIO, is provided on any platform where there is a Java 1.6 or greater runtime. It
provides very good performance. However, if EAP is running on Linux, it is possible to have even
better performance using the ASYNCIO option. This uses a thin wrapper to communicate with
the asynchronous library, AIO. The Linux kernel 2.6 or later must be running and be using one of
these file systems: ext2, ext3, ext4, JFS, or XFS. NFS will not work.
The AIO package must be installed on Linux to use the ASYNCIO option. Install the package on
RHEL 7 using the following command:
# yum install -y libaio
If ASYNCIO is specified in the journal options, and AIO libraries are not available, ActiveMQ will
fallback to NIO.
Bindings Journal
This NIO-only journal includes the set of queues that are deployed on the server and their
attributes and other data, such as ID sequence counters. This journal consists of files named
activemq-bindings-?.bindings, where ? is a sequential number. These files are stored
JB348-RHJBEAP7-en-6-20170411 229
in the EAP data directory for the server. In standalone mode, for instance, this directory is
$JBOSS_HOME/standalone/data/activemq/bindings.
A new feature in JBoss EAP 7 is the ability to define the bindings directory using the following
attributes:
• bindings-directory: The directory where the bindings journal lives. The default value is
data/bindings.
• create-bindings-dir: If this is set to true, then the bindings directory is automatically

created at the location specified in bindings-directory, if it does not already exist. The default
value is true.
Use the following CLI operations to configure the attributes:
/subsystem=messaging-activemq/server=default/path=bindings-directory:write-
attribute(name=path,value=new/dir)
/subsystem=messaging-activemq/server=default:write-attribute(name=create-bindings-
dir,value=true)
JMS Journal
All JMS related data is stored in these journals, such as JMS queues, topics, connection factories,
and their JNDI bindings. The journal consists of files named activemq-jms-?.jms, where ? is a
sequential number. These files are stored in the EAP data directory for the server. In standalone
mode, for instance, this directory is $JBOSS_HOME/standalone/data/activemq/bindings.
Message Journal
The message journal, stored over a series of pre-created files, stores all message related data.
Some things to note about these journal files:
• Append only journal: All operations performed such as add, update, and delete are
append to the journal. When a journal fills up, the next available one is used.
• File size is configurable: Optimum size for the disk can be achieved by aligning file
sizes to disk cylinder size.
• Garbage collection: As delete records are added to the journal, ActiveMQ can determine
if a particular journal file contains any active data. If it does not, it is reclaimed for re-use.
ActiveMQ can also remove dead space in the journal for re-use.
• Transactions: Journals support recording local and XA transactions.
Message journal files are stored in the $JBOSS_HOME/standalone/data/activemq/

journal folder. The file name has the format activemq-data-?.amq, where ? is a sequential
number. There are several configuration parameters for the management of the message journal.
Some are shared here:
• journal-file-size: In bytes, the size of one journal file. The default is 10485760.
Change the value with the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-file-
size,value=20971520)
230 JB348-RHJBEAP7-en-6-20170411
Message Persistence
• journal-min-files: The minimum number of files that make up the message journal. The
default is two files. Change the value with the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-min-
files,value=4)
• journal-type: Determine the type of the journal. NIO and ASYNCIO are the allowed
options. The default is ASYNCIO. Change the value with the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-
type,value=ASYNCIO)
• journal-max-io: This parameter controls the maximum number of write requests that can
be in the I/O queue at any one time. If the queue becomes full, further write I/O activity will be
blocked until space is made available. For NIO, the default is 1. For ASYNCIO, the default is 500
with a maximum less than or equal to the OS limit, /proc/sys/fs/aio-max-nr. Change the
value with the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-max-
io,value=1000)
• journal-compact-min-files: The minimum number of full journal files before the

compaction algorithm begins. Default is 10 files. Change the value with the following CLI
operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-compact-min-
files,value=20)
• journal-compact-percentage: When N percent or less of the file is active data (and

minimum files are full), the file is compacted. The default value is 30 percent. Change the value
with the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-compact-
percentage,value=25)
There are numerous other parameters provided for journaling. For more information refer to
the EAP product documentation.
It is possible to import data to ActiveMQ from the previous JBoss EAP release using HornetQ.
To accomplish this goal, use the HornetQ exporter utility to export data and the import-
journal operation from ActiveMQ to import data. For more information refer to the
Migration guide.
Large Messages
Very large messages can be sent even when the client or server are running low on memory.
The only limit to the size of the message is by the size of available space on the host where
JBoss EAP is running. Messages are sent by streaming them to the server. The server then
records fragments of the message on disk. Large messages are stored in the $JBOSS_HOME/
standalone/data/activemq/largemessages folder. The size at which a message is
considered large is determined by a setting in the connection factory, min-large-message-
JB348-RHJBEAP7-en-6-20170411 231
size. This defaults to 100 KiB, or 102400 bytes. Use the following CLI operation to change the
default value:
/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory\
:write-attribute(name=min-large-message-size,value=204800)
Paging
ActiveMQ can transparently page messages in and out of memory to disk when memory is
running low. By default, ActiveMQ pages messages. The following options are available:
• PAGE: Paging is enabled for messages.
• DROP: Messages are silent dropped when memory threshold is reached.
• FAIL: Messages are dropped when memory threshold is reached and sends an exception to
client message producers.
• BLOCK: Clients are blocked until memory is made available.
This configuration can be defined globally using the # wildcard or for a specific queue or topic.
Use the following CLI operation to change the default value globally:
attribute(name=address-full-policy,value=BLOCK)
There are other important attributes:
• max-size-bytes: In bytes, the maximum memory taken up by the queue matching this
address before entering into page mode. Note this is also the maximum for the other full policy
options. The default value is 10485760. To change the value, use the following CLI operation:
attribute(name=max-size-bytes,value=20971520)
• page-size-bytes: In bytes, the size of the page file. This size must be less than the max-
size-bytes. The default value is 2097152. Use the following CLI operation to change the
default value:
attribute(name=page-size-bytes,value=4194304)
The paging directory for EAP 7 is $JBOSS_HOME/standalone/data/activemq/paging
Considerations for Persistence, Paging, and Large Messages

There are some important aspects to consider when configuring Persistence in a MOM:
• Disk Space: Make sure that there is enough disk space allocated to handle all three of
these options. Actively monitor disk space usage and alert administrative staff if certain
thresholds are exceeded. If the production environment is running on RHEL or some other
Linux or UNIX, make sure to partition JBoss EAP into a file system other than root (/). If root
fills up, the server will be seriously impacted.
232 JB348-RHJBEAP7-en-6-20170411
Message Persistence
• Journal Size: Make sure the journal sizes are tuned to your particular usage patterns. See
the performance tuning section later in this unit.
• Hardware Write Cache: If the production disk does not have nonvolatile or battery-
backed cache and is not configured for RAID, make sure disk write cache is disabled at the
hardware level. Disabling disk write cache can have a measurable impact on journaling
performance, so use it with caution. Load test your systems.
• AIO: Run on RHEL 6 or later so that you can take advantage of the asynchronous I/O.
• Paging and Message Acknowledgement: Make sure messages are being acknowledged
regularly. Unacknowledged messages stay in memory and if the memory threshold is
exceeded, paging will increase.
References
For more information about message persistence, visit the Configuring Messaging page
of the
EAP 7 Documentation
platform/7.0/single/configuring-messaging/
JB348-RHJBEAP7-en-6-20170411 233
Guided Exercise: Configuring Message

Persistence with ActiveMQ Artemis
In this exercise, you will configure settings for the persistence journal, paging, and handling of
large messages.
Resources
Files: /home/student/JB348/labs/persistence-artemis
Outcomes
You will be able to configure various messaging persistence features.
Before you begin

Use the following command in the workstation VM to set up a standalone server, to open the
firewall ports, and to download the required messaging client application:
[student@workstation ~]$ lab persistence-artemis setup

The setup script for this guided exercise has downloaded files for a preconfigured
Standalone server created in the previous guided exercise.
Open a new terminal window from workstation and run the following command to start
the Standalone server:

-Djboss.server.base.dir=/home/student/JB348/labs/persistence-artemis/machine1/
2. Enable Persistence
Update the ProjectQueue queue so that the messages are saved in the case of a server
failure.
2.1. Open a new terminal window on the workstation VM and connect to CLI to enable
configure the persistence:

2.2. Currently, it is not possible to enable persistence for a queue that has already been
defined using the CLI. For this reason, the existing queue should be recreated. Delete
the ProjectQueue queue:
[standalone@172.25.250.254:9990 /] /subsystem=messaging-activemq/\
server=default/jms-queue=ProjectQueue:remove
234 JB348-RHJBEAP7-en-6-20170411
2.3. Recreate the queue with persistence enabled. To enable persistence, set the attribute
durable to true.

--queue-address=ProjectQueue --durable=true \
3. Configure Persistence Journal File

Update the queue with the following requirements:
• The messages are a maximum of 936 bytes in length.
• The ProjectQueue queue keeps, on average, at least 30 messages.
• No more than 10 messages per journal file.
Based on these requirements, the journal file size needs to be at least 9360 bytes. The size
must be divisible by 512, so the size should be increased to 9728 bytes.
Since the ProjectQueue keeps on average 30 messages around, the configuration needs
a minimum of 30 divided by 10, or 3, journal files. Configure the journal to the specified
requirements.
3.1. Configure the journal file size to 9728:
[standalone@172.25.250.254:9990 /] /subsystem=messaging-activemq\
/server=default:write-attribute(name=journal-file-size, value=9728)
3.2. Configure the minimum number of files that make up the message journal to 3:
[standalone@172.25.250.254:9990 /] /subsystem=messaging-activemq\
/server=default:write-attribute(name=journal-min-files,value=3)
3.3. To enable the configuration, a reload is required:
[standalone@172.25.250.254:9990 /] :reload
4. Configure Asynchronous I/O

By default, the messaging subsystem is configured to use AIO for a better performance.
Look through the startup log for message AMQ221012. This message indicates that
ActiveMQ is correctly configured to use AIO.
Verify that the libaio is installed on RHEL with the following command:
[student@workstation ~]$ sudo rpm -qa | grep libaio

libaio-0.3.109-13.el7.x86_64
5. Observe Journaling Behavior

The message-client.jar application is provided to test the persistence configuration
from the ProjectQueue queue.
JB348-RHJBEAP7-en-6-20170411 235
5.1. Open a new terminal window and run the application passing the paging argument.
This example dumps 30 messages of 936 bytes on the ProjectQueue queue.
[student@workstation ~]$ cd /home/student/JB348/apps

paging --user=jms-client --password=JBoss@RedHat123
5.2. In the terminal window running CLI, verify the number of messages in the queue:
[standalone@172.25.250.254:9990 /] /subsystem=messaging-activemq/server=default\
/jms-queue=ProjectQueue:read-attribute(name=message-count)
...
"result" => 30L
...
5.3. Look at the journal files at /home/student/JB348/labs/persistence-artemis/

machine1/data/activemq/journal/. You should see 11 journal files:
[student@workstation ~]$ ll /home/student/JB348/labs/\

persistence-artemis/machine1/data/activemq/journal/
5.4. Run the application passing the paging argument again and look at the journal files.

Observe that 10 new journal files were created.
5.5. Run the application passing the drain argument, which removes all records from the
ProjectQueue queue. Look at the journal files:

drain --user=jms-client --password=JBoss@RedHat123
The number of journal files is the same. Every time that ActiveMQ needs a new journal,
a new file is created. However, when a message is deleted, the journal file is not deleted
so that it can be used again when a new message is sent to the queue.
5.6. Run the application twice, passing the paging argument to add 60 records to the
queue. Look at the journal files and observe that no new files were created:

236 JB348-RHJBEAP7-en-6-20170411
Note
We have used extremely small journal sizes in this lab to easily show the journal
creation and compaction behaviors. You will use much larger journal sizes in
production.
6. Enable Paging
Enable paging for the ProjectQueue queue.
6.1. Enable paging on the jms.queue.ProjectQueue queue. Set the maximum amount of
memory used for this queue to 15 messages. Make the page size 5 messages. Remember
that the messages are 936 bytes each.
/address-setting=jms.queue.ProjectQueue:add(address-full-policy=PAGE,\
page-size-bytes=4680, max-size-bytes=14040)
6.2. Run the application passing the paging argument. This should have exceeded memory.

6.3. Look at the paging persistence directory to see the messages that were paged:
[student@workstation apps]$ ll /home/student/JB348/labs/\

persistence-artemis/machine1/data/activemq/paging/*
6.4. Drain the messages by running the application passing the drain argument:

drain --user=jms-client --password=JBoss@RedHat123
6.5. Look at the paging persistence directory to see that the pages were removed:

persistence-artemis/machine1/data/activemq/paging/*
7. Change the Large Message Handling

7.1. Examine the /home/student/JB348/labs/persistence-artemis/machine1/
data/activemq/largemessages directory:
[student@workstation exploring-artemis]$ ll /home/student/JB348/labs/\

persistence-artemis/machine1/data/activemq/largemessages
This directory is empty because all messages sent to the queue were smaller than the
default value configured in the connection factory.
JB348-RHJBEAP7-en-6-20170411 237
7.2. Return to the terminal that is running CLI and check the default value for the minimum
large message size:
/connection-factory=RemoteConnectionFactory:read-attribute(name=min-large-
message-size)
You should see the default value that is 102400.
7.3. Make the large message size 512 bytes on the remote connection factory:
/connection-factory=RemoteConnectionFactory\
:write-attribute(name=min-large-message-size, value=512)
7.4. To enable the configuration, a reload is required:
[standalone@172.25.250.254:9990 /] :reload
7.5. Run the application passing the paging argument. If you drained the queue in the
previous step, there should be 30 messages in the queue.

7.6. Examine the largemessages directory and confirm that there are 30 large messages
present:

persistence-artemis/machine1/data/activemq/largemessages

8.1. Run the following command to verify that the messaging subsystem was correctly
configured for persistence.
[student@workstation ~]$ lab persistence-artemis grade
8.2. Press Ctrl+C in the terminal windows where you started the instance of EAP 7 to stop
the server.
238 JB348-RHJBEAP7-en-6-20170411
Configuring Messaging Bridges
Configuring Messaging Bridges
Objectives
After completing this section, students should be able to configure a messaging bridge.
Bridges
A bridge consumes messages from a source queue and forwards them to another queue, which
is useful when administrators need to integrate two systems. The target queue is typically a
separate ActiveMQ server. The source and target servers have no restrictions, such as being in
the same network or participating in the same cluster. The bridge is built to resist failure, should
the target connection be lost. It will retry the connection until the target comes back online
and it will then restart sending messages where it left off at the time of failure. A bridge can be
configured to provide once and only once delivery guarantees in the event of a failure by using
duplicate detection, a process that ensures that a message is only received once even in the
situation where a message is received but the acknowledgement is not sent.
ActiveMQ supports two types of bridges:
• JMS Bridges
• Core Bridges
JMS Bridges
A JMS bridge consumes a message from a source queue and produces the same message in
a target queue. This operation is executed using the JMS API and can be used by different
messaging systems that support JMS.
Figure 7.4: A JMS bridge transfers a message from a source queue and places it on a target queue
To configure a JMS bridge, use the following CLI operation:
/subsystem=messaging-activemq/jms-bridge=my-bridge\
:add(quality-of-service=AT_MOST_ONCE,failure-retry-interval=10000,\
max-retries=1,max-batch-size=10,max-batch-time=100,\
source-connection-factory=ConnectionFactory,\
source-destination=java:jboss/exported/jms/queue/JMSBridgeSourceQueue, \
target-connection-factory=jms/RemoteConnectionFactory, \
target-user=jms-client, target-password=JBoss@RedHat123,\
target-destination=jms/queues/JMSBridgeTargetQueue,target-context={\
java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory,\
java.naming.provider.url=http-remoting://172.25.250.254:8080,\
java.naming.security.principal=jms-client,\
java.naming.security.credentials=JBoss@RedHat123})"
The previous CLI operation creates a bridge that consumes a message from a queue using the
JNDI name java:jboss/exported/jms/queue/JMSBridgeSourceQueue and produces
JB348-RHJBEAP7-en-6-20170411 239
the same message on the 172.25.250.254 server in a queue using the JNDI jms/queues/
JMSBridgeTargetQueue.
Observe that a credential must be provided to connect to the target server. Also, a desired
quality of service was specified. The following other qualities are available:
• AT_MOST_ONCE: Messages reach the destination from the source, at most, once. Before
sending to the destination, a message is consumed from the source and acknowledged. If a
failure occurs between consuming from the source and producing at the target, a message
could be lost.
• DUPLICATES_OK: Messages are acknowledged only after they have been successfully sent to
the destination. If a failure occurs after sending to the destination but before acknowledging
them, they can be sent again when the system recovers duplicating a message on the target.
• ONCE_AND_ONLY_ONCE: Messages reach the target once and only once. This mode is only
available for durable messages.
Another important configuration is related to batch. It is possible to define two configurations:
• max-batch-size: Defines the number of messages to consume from the source

destination before sending them in a batch to the destination.
• max-batch-time: The maximum number of milliseconds to wait before sending a batch to a

target, even if the number of messages consumed has not reached max-batch-size. A value of
-1 means to wait forever.
When a bridge detects a failure, it is possible to configure how it tries to reconnect. This can be
accomplished with two configurations:
• max-retries: The number of times to attempt to recreate connections to the source or

target servers when the bridge has detected they have failed. The bridge gives up after trying
this number of times. A value of -1 means to try forever.
• failure-retry-interval: The time in milliseconds to wait before recreating connections

to the source or target servers when the bridge detects failures.
Consult the JMS Bridge documentation for the detailed list of configuration options.
Core Bridges
A core bridge consumes and produces a message using the core API and are only available
between any two JBoss EAP messaging.
To configure a core bridge, use the following CLI operation:
/subsystem=messaging-activemq/server=default/bridge=my-core-bridge\
:add(static-connectors=[bridge-connector],queue-name=jms.queue.InQueue\
user=jms-client, password=JBoss@RedHat123\
forwarding-address=jms.queue.TargetQueue
)
The bridge-connector is a static connector defining the target server. This bridge consumes
messages from a queue using the jndi queue-name=jms/queue/InQueue and produces the
same message in a queue using the jndi jms/queue/TargetQueue .
240 JB348-RHJBEAP7-en-6-20170411
Bridges
A credential must be provided to connect to the remote server using a core bridge. Consult the
Core Bridges documentation for the detailed list of configurations.
References
Visit the Configuring JMS Bridges section of the
EAP 7 Documentation
platform/
JB348-RHJBEAP7-en-6-20170411 241
Guided Exercise: Configuring Messaging

Bridges
In this exercise, you will configure a new bridge that consumes a message from servera and
forwards the message to serverb.
Resources
Files: /home/student/JB348/labs/bridge
Outcomes
You will be able to configure a JMS bridge.
Before you begin

Use the following command in the workstation VM to set up the EAP environment, to open the
firewall ports, and to download the required applications:
[student@workstation ~]$ lab bridge setup
1. Start the Servers

The setup script for this guided exercise has downloaded files for a preconfigured
standalone server on servera and serverb.
1.1. Open a new terminal window from workstation and access the servera VM using
the ssh command:
Start the standalone server:

[student@servera bin]$ ./standalone.sh -c standalone-full.xml \
-Djboss.server.base.dir=/home/student/JB348/labs/bridge/machine1/
1.2. Open a new terminal window from workstation and access the serverb VM using
the ssh command:
Start the standalone server:

[student@serverb bin]$ ./standalone.sh -c standalone-full.xml \
-Djboss.server.base.dir=/home/student/JB348/labs/bridge/machine1/
2. Create the Queues

Create two queues to form the bridge. The first should be created in the source server while
the second should be created on the target server. Create two new queues with the following
characteristics:
242 JB348-RHJBEAP7-en-6-20170411
• Source Queue:
◦ Server: servera
◦ Name: JMSBridgeSourceQueue
◦ JNDI: java:jboss/exported/jms/queue/JMSBridgeSourceQueue
◦ Durable: true
• Target Queue:
◦ Server: serverb
◦ Name: JMSBridgeTargetQueue
◦ JNDI: java:jboss/exported/jms/queues/JMSBridgeTargetQueue
◦ Durable: true
2.1. Open a new terminal window from the workstation VM and create the source queue
by executing the create-queue.sh script available in the /home/student/JB348/
labs/bridge folder:
[student@workstation ~]$ cd /home/student/JB348/labs/bridge

[student@workstation bridge]$ ./create-queue.sh servera JMSBridgeSourceQueue \
java:jboss/exported/jms/queue/JMSBridgeSourceQueue true
2.2. Create the target queue:
[student@workstation bridge]$ ./create-queue.sh serverb JMSBridgeTargetQueue \

java:jboss/exported/jms/queues/JMSBridgeTargetQueue true
3. Configure the JMS Bridge

Configure a new JMS Bridge with the following characteristics:
• Name: project-bridge
• Max batch time: 100
• Max batch size: 10
• Max retries: 1
• Failure retry interval: 10000
• Quality of service: AT_MOST_ONCE
• Source destination: java:jboss/exported/jms/queue/JMSBridgeSourceQueue
• Source server: servera
• Target user: jms-client
JB348-RHJBEAP7-en-6-20170411 243
• Target password: JBoss@RedHat123
• Target server: serverb
• Target Destination: jms/queues/JMSBridgeTargetQueue
3.1. To configure the bridge, update the variables in the /home/student/JB348/labs/

bridge/bridge.sh script with the specified characteristics.
3.2. Run the script to create the bridge:
[student@workstation bridge]$ ./bridge.sh
You should see the following output:
Creating the bridge
Bridge created successfully.
4. Test the bridge

[student@workstation bridge]$ ssh servera
4.2. The message-client.jar application is provided to test the queue. Run the
application passing the bridgesend argument. This will send one message to the
JMSBridgeSourceQueue queue.
[student@servera ~]$ cd /home/student/JB348/labs/bridge

[student@servera bridge]$ java -jar messaging-client.jar \
bridgesend --user=jms-client --password=JBoss@RedHat123
...
Message sent.
4.3. Connect to CLI to verify that the JMSBridgeSourceQueue queue received a message
and that the message was forwarded to the target queue:

[student@servera bin]$ ./jboss-cli.sh --connect --user=jbossadm \
4.4. Verify that the queue received a message and that the message was forwarded to the
target queue:
/jms-queue=JMSBridgeSourceQueue:read-resource(include-runtime=true)
244 JB348-RHJBEAP7-en-6-20170411
One message was added to the queue based on the messages-added attribute. The
queue, however, does not have any messages based on the message-count attribute.
This means that the message was forwarded to another queue.
4.5. Exit the CLI:
[standalone@172.25.250.10:9990 /] exit
[student@servera bin]$ ssh serverb
4.7. Connect to CLI to verify that the JMSBridgeTargetQueue queue received the
forwarded message:

[student@serverb bin]$ ./jboss-cli.sh --connect --user=jbossadm \
4.8. Verify that the queue received the forwarded message:
/jms-queue=JMSBridgeTargetQueue:read-resource(include-runtime=true)
Observe that the queue has the forwarded message with the message-count
attribute.
4.9. Exit the CLI:
[standalone@172.25.250.11:9990 /] exit

5.1. Run the following command on the workstation VM to verify that the bridge was
correctly configured.
[student@workstation ~]$ lab bridge grade
the servers.
JB348-RHJBEAP7-en-6-20170411 245
Configuring the Messaging Cluster for High

Availability
Objectives
After completing this section, students should be able to manage ActiveMQ Artemis for high
availability messaging.
Enable Cluster in ActiveMQ Artemis

ActiveMQ Artemis servers can work in a cluster, sharing the processing load. Each active node
in the cluster manages its own messages and handles its own connections. To enable messaging
clustering, the server must first be configured to be clustered. Clustering is disabled by default in
the full profile for both domain and standalone modes, but it is enabled in the full-ha profile.
The following configuration enables Artemis clustering on the server:
...
<cluster password="myPassword" user="myUser"/>
...
<cluster-connection name="my-cluster" discovery-group="dg-group1" connector-
name="http-connector" address="jms"/>
</subsystem>
The cluster user name and password configuration is not required, as default credentials are
provided, but it is an important security practice to change it. The ActiveMQ servers can self-
discover and join a cluster, and if the default settings for network addresses and ports are left
unchanged, it is highly likely that an unwanted server will try to join the group. If the user name
and password are set to its default, the rogue server can join the cluster if it is accessible on the
network.
Automatic Discovery
ActiveMQ Artemis servers can broadcast their connection details allowing other servers to
discover them and form a cluster. There are two ways to setup automatic discovery:
• UDP (Multi-casting): This is the easiest way to configure discovery. Each server
broadcasts its details over UDP and each server discovers other servers over UDP.
• Static Connectors: In cases where UDP is not allowed, it is possible to define the address
of a reliable server or servers to connect to. This has the benefit of the servers automatically
picking up connection details and automatically configuring the cluster.
Automatic discovery is not only used for connecting servers to a cluster, it can be used by
messaging clients that are attempting to find a clustered server to connect to. Through
automatic discovery, the client can stay informed about which nodes are available as they join
or leave the cluster during the client's runtime. The client works with the servers according to
whatever policy is configured. By default, the client communicates with nodes in a round-robin
fashion, spreading the processing load on the servers.
There are two entities that must be configured: the broadcast group and discovery group.
246 JB348-RHJBEAP7-en-6-20170411
Cluster Connections
The broadcast group defines how the server broadcasts how other servers can connect to it. The
following is its default configuration:
<broadcast-group name="bg-group1" connectors="http-connector" jgroups-
channel="activemq-cluster"
Refers to a connector definition on this server. This is the connector that other servers or
clients can connect to.
The name used by a JGroups channel to join a cluster.
The discovery group defines how connector information is received from a multicast address.
As it receives broadcasts on the multicast group address from a particular server, it updates its
entry in the list of available servers. If it has not received a broadcast from a particular server
for a given length of time, it removes that server's entry from its list. The following is the default
discovery group configuration:
<discovery-group name="dg-group1" jgroups-channel="activemq-cluster"/>
Cluster Connections
An ActiveMQ Artemis cluster is formed by each node declaring cluster connections to other
nodes through broadcast and discovery, or static discovery. When a node forms a cluster
connection to another node, internally it creates a core bridge connection between it and
the other node. This core bridge is automatically configured. These cluster connections allow
messages to flow between the nodes of the cluster to balance load. The default configuration in
the full-ha profile:
<cluster-connection name="my-cluster" discovery-group="dg-group1" connector-
name="http-connector" address="jms" />
This names the discovery group that is used to discover other nodes and tell them about
this connection.
This specifies which connector which is used in the connection with other servers.
Each cluster connection applies to messages sent to an address that starts with this value.
In this case, jms matches any JMS queue or topic because their internal ActiveMQ Artemis
queue names start with jms.queue. Multiple cluster connections can match on different
addresses, similar to the <address-setting> configuration element. Wildcards cannot be
used in this parameter.
Message Redistribution
If the consumers on a queue close after the messages have been sent to the node, the messages
are not consumed. ActiveMQ Artemis can be configured to redistribute messages from queues
on one node in the cluster that have no consumers to other nodes which have a matching
consumer. The configuration is part of the <address-setting> element.
<address-setting name="#" redistribution-delay="1000" ... />
The default value for redistribution-delay is -1, which disables the feature. Message
redistribution can be configured to kick in immediately after the last consumer on the queue is
JB348-RHJBEAP7-en-6-20170411 247
closed by setting the value to 0. Any value greater than 0 is the number of milliseconds to wait
until after the last consumer is closed, before redistributing the messages to other nodes.
References
Visit the Clustering Overview section in the
EAP 7 Documentation
https://access.redhat.com/documentation/en-us/
red_hat_jboss_enterprise_application_platform/
248 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Configuring the Messaging Cluster
Guided Exercise: Configuring the Messaging

Cluster
In this exercise, you will configure and explore a messaging cluster.
Resources
Files: /home/student/JB348/labs/jms-client-cluster
Outcomes
You should be able to configure a messaging cluster to load balance ActiveMQ messages.
Before you begin

Use the following command in the workstation VM to set up an EAP cluster, open firewall
ports, and download the messaging-client.jar application:
[student@workstation ~]$ lab jms-client-cluster setup

The setup script for this guided exercise has downloaded files for a preconfigured managed
domain.
1.1. In a new terminal window on workstation, run the following commands to start the
domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/jms-client-cluster/machine1/ \
1.2. Open a terminal window on the workstation VM and access the servera VM using
SSH:

the ssh command:
JB348-RHJBEAP7-en-6-20170411 249

Note
You will see an error related to authentication in the server logs. This can be
safely ignored for now.
2. Fix the Authentication Problem

The cluster is using the default password, which is CHANGE ME!!. Since this password is not
the correct password configured in the mgmt-users.properties file, the server starts up
with errors.
2.1. Open a new terminal window on workstation and connect to CLI to change the
cluster password:

2.2. Update the cluster password to JBoss@RedHat123:
[domain@172.25.250.254:9990 /] /profile=full-ha/subsystem=messaging-activemq/\
server=default:write-attribute(name=cluster-password, value=JBoss@RedHat123)
2.3. Reload the hosts to enable the new password:
[domain@172.25.250.254:9990 /] /host=host2:reload
The server logs no longer present the authentication error.
3. Create a clustered queue

The project requires a new queue with the following characteristics:
• Name: ClusterProjectQueue
• JNDI: java:jboss/exported/jms/queue/ClusterProjectQueue
• Durable: true
Using the EAP CLI, create the ClusterProjectQueue queue:
[domain@172.25.250.254:9990 /] jms-queue add --profile=full-ha \

--queue-address=ClusterProjectQueue \
--entries=java:jboss/exported/jms/queue/ClusterProjectQueue --durable=true
250 JB348-RHJBEAP7-en-6-20170411
4. Test the Messaging Cluster
4.1. Run the message-client.jar application, passing the clsend argument to send
messages to the cluster. Use the --totalMessages parameter to send 10 messages to
the cluster. Use the following commands on the workstation to send the messages to
the cluster:

clsend --totalMessages=10 --user=jms-client --password=JBoss@RedHat123
4.2. Verify the number of messages on each server using the verifyMessages.sh script:
[student@workstation apps]$ cd /home/student/JB348/labs/jms-client-cluster/

[student@workstation jms-client-cluster]$ ./verifyMessages.sh
Getting messaging info ...

Queue ClusterProjectQueue from server cluster-one on host host2
Number of messages in the queue: 10L
Queue ClusterProjectQueue from server cluster-two on host host3

All of the messages are available only in one server, indicating that the load balancing
is not working. A proper load balancer evenly distributes the message load between the
available servers.
4.3. Drain all the messages from the cluster, passing the argument cldrain to the
messaging-client.jar application:
[student@workstation jms-client-cluster]$ cd /home/student/JB348/apps

cldrain --user=jms-client --password=JBoss@RedHat123
4.4. Verify that all of the messages were drained from the cluster:

5. Fixing the Load Balancer

The messaging server from the host3 host does not queue any messages because
ActiveMQ default settings do not deliver messages to cluster members that have no active
consumers. This is done to avoid unnecessary network traffic. In this scenario, however, this
default setting must be replaced from ON_DEMAND to STRICT to create a "round-robin" style
load balancing of the messages for external clients.
5.1. Return to the terminal that is running CLI and change the default setting of the
property message-load-balancing-type:
JB348-RHJBEAP7-en-6-20170411 251
server=default/cluster-connection=my-cluster\
:write-attribute(name=message-load-balancing-type, value=STRICT)
5.2. Reload the hosts to enable the new configuration:
6. Retest the Messaging cluster

6.1. Send 30 messages to the cluster using the messaging-cluster.jar application:

clsend --totalMessages=30 --user=jms-client --password=JBoss@RedHat123
6.2. Verify that the load balancer is evenly distributing messages using the
verifyMessages.sh script:

Getting messaging info ...

Queue ClusterProjectQueue from server cluster-one on host host2
Queue ClusterProjectQueue from server cluster-two on host host3

All messages are now distributed between the two servers.
6.3. Drain all of the messages from the cluster using the messaging-client.jar application:

cldrain --user=jms-client --password=JBoss@RedHat123
7. Grading and Cleaning Up

configured.
[student@workstation ~]$ lab jms-client-cluster grade
7.2. Press Ctrl+C in the terminal windows running EAP 7 to stop the servers.
252 JB348-RHJBEAP7-en-6-20170411
Tuning Messaging Performance
Tuning Messaging Performance
Objectives
After completing this section, students will be able to tune the messaging system for optimal
performance.
Performance Tuning
The ActiveMQ Artemis server embedded in the JBoss EAP 7 already ships with a configuration
that provides good performance for almost every application. Many applications, however, need
additional configuration in order to fully optimize performance. The messaging server can be
tuned based on the following considerations:
• Optimum configurations for persistence.
• JMS API tuning.
• Advanced send and acknowledgement techniques.
• Core API and JMS API.
• Transport settings.
• Virtual Machine tuning.
• Avoiding bad design patterns.
Optimum configurations for persistence.

A major factor in performance is whether messages are persisted to disk or not. If not, making
the queue not durable avoids an unnecessary use of read and writes from disk, which greatly
improves performance.
If a message is saved on the disk and the servers are running on Linux, define the journal type as
ASYNCIO. This option greatly increases the amount of operations to disk per second. Change the
journal type with the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-type,
value=ASYNCIO)
The $JBOSS_HOME/standalone/data/activemq/journal folder contains all of the journal

files for the messaging server. If new files are being created too often, the minimal number of
journal files should be increased to reuse more files instead of creating new ones as much as
possible. Change the minimum of created files with the following CLI operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-min-
files,value=10)
To further optimize journaling, align the journal file size with the capacity of one cylinder on the
disk. This minimizes the amount of disk head movement. Update the journal file size with the
following CLI operation:
JB348-RHJBEAP7-en-6-20170411 253
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-file-
size,value=20971520)
Adjust the journal buffer timeout to meet the application needs. The timeout is increased to
increase throughput, but at the expense of latency. Update the timeout with the following CLI
operation:
/subsystem=messaging-activemq/server=default:write-attribute(name=journal-buffer-
timeout, value=500)
If possible, place the messaging journal on its own physical volume to minimize disk head
movement. If the messages do high volumes of paging or of large messages, performance is
improved by putting paging and large message files on a separate volume.
By default, after reaching 10 MB of memory, the messages are written to disk. Increase this value
according to the number of messages that are received on the server. To increase this value, use
the following CLI operation:
/subsystem=messaging-activemq/server=default/address-setting=#:add(max-size-
bytes=51200000)
JMS API tuning

Each message on the broker has a unique identifier in the header to be used by a JMS
application for a number of purposes, such as correlating requests and sending reply messages.
This identifier does require additional time and resources to be created, and increases the final
size of a message. If a JMS applications does not require identification, disable it to improve
the performance. Development teams should use the following code to disable the message
identifier:
MessageProducer producer = session.createProducer(myQueue);

producer.setDisableMessageID(true);
Also, each message on the broker has a time stamp in the header, representing the processing
time. This time stamp increases the final size of a message. If it is not required, disable it to
improve the performance. The following code should be used to disable the time stamp:
MessageProducer producer = session.createProducer(myQueue);

producer.setDisableMessageTimestamp(true);
Developers should also avoid using object messages. The serialization overhead and size of the
data being transferred may outweigh the benefits.
Another good practice is to batch as many messages to one acknowledgement as possible.

This means avoiding the use of AUTO_ACKNOWLEDGE mode on the session. Instead, use
CLIENT_ACKNOWLEDGE or a transacted session. ActiveMQ Artemis requires only a network
round trip on a transaction commit. This applies to sending messages as well.
Advanced Sending
For better performance, consider the following tips for sending messages:
• Use asynchronous send acknowledgements instead of blocking.
254 JB348-RHJBEAP7-en-6-20170411
Performance Tuning
• Use pre-acknowledge mode so that messages are acknowledged before they are sent to the
client.
• Set <journal-sync-transactional> to false to synchronize transactions lazily. This

increases the possibility of loss of transactions in failure situations.
• Set <journal-sync-non-transactional> to false to synchronize message persistence

lazily. This increases the possibility of messages not being saved in failure situations.
• Set <block-on-durable-send> and <block-on-non-durable-send> to false. This frees

the client from waiting a whole network round trip for every message sent.
Core API and JMS API

For the best performance, use the ActiveMQ Artemis core Java API instead of JMS. This gives
a slight performance increase because JMS operations are not being translated into core
operations. The ActiveMQ Artemis JMS implementation is a facade in front of the core API.
Developers using the core API can use the SimpleString class without fear of a
degraded performance. This class does not require copying before it is sent unlike the
java.lang.String class.
Tuning the Transport

Another adjustment administrators can adjust on the messaging subsystems is the connector
and acceptor configuration. If the environment has a fast network, and the servers are fast, then
it is possible to get a performance boost by increasing the TCP send and receive buffer sizes.
Note
Later versions of Linux (and possibly other operating systems) include TCP auto-
tuning. Setting TCP buffer sizes manually can prevent this feature from working and
render poorer performance.
If many concurrent connections to servers are expected, or if clients are rapidly opening and
closing connections, make sure the user account running the server has permission to create
sufficient file handles. In RHEL, this is configured in the /etc/security/limits.conf file.
Tuning the Virtual Machine

Use parallel garbage collection if it is available in the server vendor's JVM, and give as much
memory to the server as possible. Low memory situations result in paging to disk. Increase the
memory for ActiveMQ Artemis by increasing memory for JBoss EAP.
A load testing environment makes an ideal place to try out new settings to see if they have a
positive impact on the performance of your JBoss EAP instances.
Avoid Bad Design Patterns

Bad developer code can cause serious performance problems. Developers need to be aware of
the following good practices:
• Reuse connections, sessions, consumers, and producers as much as possible. These are the
expensive objects to create because their creation takes several network round trips.
• Use message content structures that are as lean as possible. Avoid XML if you can because it
has lots of redundant space usage. Smaller message bodies mean faster transmit times.
JB348-RHJBEAP7-en-6-20170411 255
• In the request-response pattern, do not create a temporary queue for each response. Use a
correlation ID instead or some other matching algorithm.
• If a project is using Message Driven Beans (MDB), consider whether that is the best way to
execute a consumer. It is possible to reap a huge performance gain by using a traditional
message client.
References
Visit the Performance Tuning page of the
EAP 7 Documentation
256 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Configuring and Tuning the Messaging System
Guided Exercise: Configuring and Tuning the

Messaging System
In this exercise, you will tune the messaging subsystem to optimize performance.
Resources
Files: /home/student/JB348/labs/messaging-tuning
Outcomes
You will be able to make adjustments to the messaging subsystem to optimize performance.
Before you begin

Use the following command in the workstation VM to configure a standalone server and open
the firewall ports, and to download the messaging client application:
[student@workstation ~]$ lab messaging-tuning setup
During this lab, use the messaging-client.jar application to test the performance of the
messaging subsystem with the perf argument. The /home/student/JB348/labs/
messaging-tuning/perf.properties file contains different properties that can be adjusted
to maximize performance.

The set up script for this guided exercise has downloaded files for a preconfigured
standalone server.
Open a new terminal window on workstation and run the following command to start the
standalone server:

-Djboss.server.base.dir=/home/student/JB348/labs/messaging-tuning/machine1/

The development team has created a new application that requires the messaging
subsystem to integrate with a legacy system. Create a new queue with the following
characteristics:
• Queue Name: PerfQueue
• JNDI Name: java:/jboss/exported/jms/queue/PerfQueue
• Persistence: No
2.1. Open a new terminal window on the workstation VM and connect to the EAP CLI to
create the queue:
JB348-RHJBEAP7-en-6-20170411 257


--queue-address=PerfQueue --durable=true \
--entries=java:/jboss/exported/jms/queue/PerfQueue
3. Improving performance with development

The original perf.properties file is configured to simulate unoptimized ActiveMQ
Artemis settings. Update the settings the improve the performance of the messaging
subsystem.
3.1. Open a terminal window on the workstation VM. Run the messaging-client.jar
application and take note of the time required to send 5000 messages:

[student@workstation apps]$ java -jar messaging-client.jar perf \
/home/student/JB348/labs/messaging-tuning/perf.properties
3.2. Edit the perf.properties file and increase the batch-size property to 3000. Run
the application and observe the drastic performance improvements:

4. Improving the persistence performance

4.1. This standalone server is configured to use the journal type NIO. EAP running on Linux
can have a better performance using the ASYNCIO. Return to the terminal that is
running CLI and enable the ASYNCIO journal type:
:write-attribute(name=journal-type, value=ASYNCIO)
4.2. Reload the server to enable the configuration:
[standalone@172.25.250.254:9990 /] /:reload
4.3. Test the application and see that the performance has improved:

4.4. By default, a queue can consume 10485760 bytes of memory. JBoss EAP messaging
starts paging messages to disk when the size of messages in memory for a particular
address exceeds the maximum configured message size. For this application, 5000
messages of 2048 bytes each are sent to the server, exceeding the limit of bytes.
258 JB348-RHJBEAP7-en-6-20170411
Update the maximum bytes to avoid paging messages to disk in order to improve the
performance. The minimum size is 10240000 bytes (5000 * 2048), however, you want
to support at least 5 clients without paging messages to disk. The value should be
51200000 bytes:
/address-setting=jms.queue.PerfQueue:add(max-size-bytes=51200000)
4.5. Test the application and notice the improved performance:


5.1. Run the following command to verify that the server messaging system was optimized:
[student@workstation apps]$ lab messaging-tuning grade
the server.
JB348-RHJBEAP7-en-6-20170411 259
Lab: Messaging System Configuration and

Tuning
In this lab, you will configure the messaging subsystem by creating and managing a queue.
Resources
Files: /home/student/JB348/messaging
Outcomes
You should be able to configure the messaging subsystem.
Before you begin

Use the following command to verify that an instance of EAP is installed in the /opt directory, to
configure the firewall, and to download the required files for this exercise:
[student@workstation ~]$ lab messaging setup

connecting to the domain controller running on 172.25.250.254. Set the base directory
for each to /opt/domain and set the node name to be servera or serverb, depending on
where the host controller is running.
2. Using the EAP CLI on the workstation VM, create a new queue with the following
properties:
• Name: LabQueue
• JNDI: java:/jboss/exported/jms/queue/LabQueue
• Persistence: true

There is a nonfunctional requirement that the message must be redirected to another queue
if it is not consumed within five seconds. Configure a new expiry queue to receive expired
messages from the LabQueue with the following properties:
• Name: LabQueueEXQ
• JNDI: java:/jboss/exported/jms/queue/LabQueueEXQ
• Persistence: no
260 JB348-RHJBEAP7-en-6-20170411
A message should also try to be delivered, at most, three times. After three attempts, the
message should be redirected to another queue. Configure a new DLQ queue to receive
redelivered messages from the LabQueue with the following properties:
• Queue Name: LabQueueDLQ
• JNDI Name: java:/jboss/exported/jms/queue/LabQueueDLQ
• Persistence: No
5. Tune the persistence

Consider the requirement that the messages must be a maximum of 1305 bytes in length
and that the LabQueue queue must keep on average at least 50 messages. In addition, limit
the journal to not have more than 10 messages per journal file. Configure the journal size for
a better performance.
6. Create a new credential with the following properties to send and receive messages:
• Username: lab-user
• Password: Lab@2017!
• Group: guest
7. Test the Queue

The /home/student/JB348/apps/messaging-client.jar application is provided to test the
queue. Use the argument labsend to send messages and labdrain to drain messages.
Before sending messages, remember to configure the load balancer to balance messages
from external clients. Send 100 messages to the queue passing the following parameters:
• --user: lab-user
• --password: Lab@2017!
• --totalMessages: 100

[student@workstation ~]$ lab messaging grade
JB348-RHJBEAP7-en-6-20170411 261
Solution
In this lab, you will configure the messaging subsystem by creating and managing a queue.
Resources
Files: /home/student/JB348/messaging
Outcomes
You should be able to configure the messaging subsystem.
Before you begin

Use the following command to verify that an instance of EAP is installed in the /opt directory, to
configure the firewall, and to download the required files for this exercise:
[student@workstation ~]$ lab messaging setup

connecting to the domain controller running on 172.25.250.254. Set the base directory
for each to /opt/domain and set the node name to be servera or serverb, depending on
where the host controller is running.
On the workstation:
student@workstation ~]$ cd /opt/jboss-eap-7.0/bin

On servera:

On serverb:

2. Using the EAP CLI on the workstation VM, create a new queue with the following
properties:
262 JB348-RHJBEAP7-en-6-20170411
Solution
• Name: LabQueue
• JNDI: java:/jboss/exported/jms/queue/LabQueue
• Persistence: true
[student@workstation bin]$ sudo -u jboss /opt/jboss-eap-7.0/bin/jboss-cli.sh \

-c --controller=172.25.250.254:9990
2.2. Create the queue:

--queue-address=LabQueue \
--entries=java:/jboss/exported/jms/queue/LabQueue --durable=true

There is a nonfunctional requirement that the message must be redirected to another queue
if it is not consumed within five seconds. Configure a new expiry queue to receive expired
messages from the LabQueue with the following properties:
• Persistence: no
properties:

--queue-address=LabQueueEXQ \
--entries=java:/jboss/exported/jms/queue/LabQueueEXQ --durable=false
3.2. Configure a new address settings to redirect expired messages:
server=default/address-setting=jms.queue.LabQueue\
:add(expiry-address=jms.queue.LabQueueEXQ,expiry-delay=5000)

A message should also try to be delivered, at most, three times. After three attempts, the
message should be redirected to another queue. Configure a new DLQ queue to receive
redelivered messages from the LabQueue with the following properties:
JB348-RHJBEAP7-en-6-20170411 263
• Persistence: No
properties:

--queue-address=LabQueueDLQ --durable=false \
--entries=java:/jboss/exported/jms/queue/LabQueueDLQ
:write-attribute(name=dead-letter-address, value=jms.queue.LabQueueDLQ)
5. Tune the persistence

Consider the requirement that the messages must be a maximum of 1305 bytes in length
and that the LabQueue queue must keep on average at least 50 messages. In addition, limit
the journal to not have more than 10 messages per journal file. Configure the journal size for
a better performance.
5.1. Based on these requirements, the journal file size needs to be at least 65250 bytes. The
size must be divisible by 512, so increased the size to 65536 bytes. Configure the journal
file size to 65536:
[domain@172.25.250.254:9990 /] /profile=full-ha/subsystem=messaging-activemq\
5.2. Since the LabQueue keeps on average 50 messages, the configuration needs a
minimum of 5 journal files. Configure the minimum number of files that make up the
message journal to 5:
5.3. To enable the configuration, reload the hosts:
[domain@172.25.250.254:9990 /] /host=servera:reload
[domain@172.25.250.254:9990 /] /host=serverb:reload
6. Create a new credential with the following properties to send and receive messages:
• Username: lab-user
• Password: Lab@2017!
264 JB348-RHJBEAP7-en-6-20170411
Solution
• Group: guest
6.1. Open a terminal window on the workstation VM and access the servera VM using SSH:
6.2. Create the credential:
[student@servera ~]$ cd /opt/jboss-eap-7.0/bin/

[student@servera bin]$ sudo -u jboss ./add-user.sh \
-dc /opt/domain/configuration -g guest -u lab-user \
-p Lab@2017! -a
6.3. Exit from servera:
[student@servera bin]$ exit
6.4. Access the serverb VM using SSH:
6.5. Create the credential:
[student@serverb ~]$ cd /opt/jboss-eap-7.0/bin/

[student@serverb bin]$ sudo -u jboss ./add-user.sh \
-p Lab@2017! -a
6.6. Exit from serverb:
[student@serverb bin]$ exit
7. Test the Queue

The /home/student/JB348/apps/messaging-client.jar application is provided to test the
queue. Use the argument labsend to send messages and labdrain to drain messages.
Before sending messages, remember to configure the load balancer to balance messages
from external clients. Send 100 messages to the queue passing the following parameters:
• --password: Lab@2017!
7.1. Return to the terminal that is running the CLI and configure the load balancer:
/server=default/cluster-connection=my-cluster\
JB348-RHJBEAP7-en-6-20170411 265
7.2. Reload the hosts to enable the configuration:
7.3. Open a terminal window on the workstation VM and send the 100 messages:

labsend --user=lab-user --password=Lab@2017! --totalMessages=100
Note
If you receive an error message, check if the servers are already booted. If
not, wait for the servers to finish booting.
7.4. Drain all messages from the queue:

labdrain --user=lab-user --password=Lab@2017!

[student@workstation ~]$ lab messaging grade
266 JB348-RHJBEAP7-en-6-20170411
Summary
Summary
• HornetQ was replaced in EAP7 by ActiveMQ Artemis.
• http and in-vm acceptors and connectors are available to access message queues/topics.
• Message expiration can be customized by editing the scan-period attribute from the
<message-expiry> element.
• Message redelivery can be changed on a queue basis.
• JBoss CLI supports an easier syntax to create queues (jms-queue), however manipulating
configuration for message expiration and redelivery can be changed only by using the DMR
syntax.
• Message persistence is not enabled by default, but if it is enabled, use the ASYNCIO option to
optimize performance.
• Message persistence generates journal files that are stored in a local file system.
• ActiveMQ supports bridges that allow message forwarding to other queues.
• Cluster support is provided through JGroups. This setup requires that a custom discovery
group be configured in the ActiveMQ subsystem.
JB348-RHJBEAP7-en-6-20170411 267
268
TRAINING
CHAPTER 8
SECURING APPLICATIONS
Overview
Goal Configure security settings to restrict authorization and
authentication to secure Java EE applications.
Objectives • Describe strategies for securing applications.
• Implement role-based access control.
• Implement Single Sign-on with Red Hat Identity

Management.
Sections • Securing Applications (and Guided Exercise)
• Defining Role Based Access Control (and Guided Exercise)
• Securing Applications with Red Hat Identity Management

Lab • Securing Applications
JB348-RHJBEAP7-en-6-20170411 269
Chapter 8. Securing Applications
Securing Applications
Objectives
After completing this section, students will be able to describe strategies for securing
applications.
Authentication
The starting point for administrators deciding on a strategy to secure an application is managing
authentication. Authentication refers to identifying a subject, for example a user, attempting
to log in to an application, and then verifying the authenticity of the credentials. In most cases,
these credentials are a user name and password combination that the server evaluates. In JEE
and EAP, a successful authentication is referred to as a principal.
By default, EAP provides security domains and security realms that make it easy to implement
basic authentication.
Security Realms and Security Domains

A security realm stores information about user names, passwords, and group membership
that can be used when authenticating users in web applications or in the management
interface. There are two configured security realms by default, the ManagementRealm and
the ApplicationRealm. The ManagementRealm is responsible for authorization and
authentication to the management interface, and the ApplicationRealm is the default realm
available for web applications and EJBs to authenticate and authorize users. By default, each of
these security realms use the file system to store user membership and credential information.
The ManagementRealm, for example, stores user credentials in the mgmt-users.properties
file, and the ApplicationRealm stores credentials in the application-users.properties
file.
A security domain is a set of security configurations that an application uses to control

authentication and authorization. By default, there are four security domains included in EAP,
and administrators can add additional custom security domains. The four default domains are
listed below:
• [Definition: jboss-ejb-policy]: The default authorization security domain for EJB modules in
applications that have not defined a security-domain explicitly.
• [Definition: jboss-web-policy]: The default authorization security domain for web modules in
applications that have not defined a security-domain explicitly.
• [Definition: other]: This security domain is used internally by JBoss EAP for authorization and
is required for correct operation.
• [Definition: jaspitest]: The jaspitest security domain is a simple Java Authentication Service
Provider Interface for Containers (JASPIC) security domain included for development
purposes.
Because the security domains are managed in the security subsystem, they can be updated in
a single standalone instance of EAP, or can be pushed out to host controllers from a configured
domain controller.
270 JB348-RHJBEAP7-en-6-20170411
Securing an Application
Figure 8.1: The security subsystem architecture and interactions with EAP
Web applications can only use security domains directly, not security realms. Security domains,
however, can be configured to use the security realms as a means of providing the identity
store, therefore allowing web applications to use security realms by enabling a security
domain to point to a security realm's identity store. For example, a web application can refer
to the default security domain other that allows applications to specify a security realm
to use for authentication and authorization information. By default, other refers to the
ApplicationRealm.
Securing web applications for authentication and authorization is achieved by using one
of several available login modules that can be defined in the security domain. For example,
the database login module uses a configured data source with custom SQL commands to
authenticate and authorize users.
Securing an Application
After creating a custom security domain, the domain needs to be included in the application's
jboss-web.xml file:
<security-domain>Security_Domain_Name</security-domain>
JB348-RHJBEAP7-en-6-20170411 271
Referencing the security domain in the jboss-web.xml file enables configuration of the
security constraints in the web.xml file. The security constraints are configured as follows:
<security-constraint>
<web-resource-collection>
<web-resource-name>All resources</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
The <url-pattern> refers to which resources or paths the security constraint applies to.
For example, setting secure.xhtml means that any security restrictions that are applied in
the <security-constraint> tag are in effect when users visit secure.xhtml. Setting the
pattern to * (asterisk) means that all resources are secured by this security constraint.
Authentication Methods
The web.xml file also defines the type of authentication to secure the application:
...
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
The available authorization methods are as follows:
• [Definition: BASIC]: The server requests a user name and password from the web client.
• [Definition: DIGEST]: The server applies a hash function to the credentials before sending them
over a network to verify the identity.
• [Definition: FORM]: The server uses form information entered by the user to verify the identity
of a user.
• [Definition: CLIENT-CERT]: The server sends a certificate and a request that must be provided
by the user to verify the identity.
FORM-based authentication also requires some additional fields to be included in the <login-
config> element:
...
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
<form-login-config>
</login-config>
The form-login-page refers to the page that contains the form for users to log in. If a user
attempts to access a secure page, they are redirected to this login page. The form-error-
page is where users are redirected if there is an error validating the user. After a user has been
validated, they are assigned a session ID that is stored as a cookie. The server expects that
272 JB348-RHJBEAP7-en-6-20170411
Authentication Methods
cookie for any subsequent request from that user. If the session expires due to inactivity, that
user will need to re-authenticate.
References
Refer to the Security Architecture section of the
EAP 7 Documentation
red_hat_jboss_enterprise_application_platform
JB348-RHJBEAP7-en-6-20170411 273
Guided Exercise: Securing an Application
In this exercise, you will set up FORM authentication with a database login module.
Resources
Files: /home/student/JB348/apps/jb348-form-auth.war
Application URL: http://localhost:8080/jb348-form-auth
Outcomes
You will be able to configure FORM authentication.
Before you begin

On workstation, run the following command to verify that an instance of EAP is installed in the
/opt/ directory and to download the secure application:
[student@workstation ~]$ lab secure-app setup
1. Create a New Administrative Application User

Before accessing the secure application, use the add-user.sh script to create a new
administrative user. This user has full access to the application. Create the user with the
name ralph and password RedHatRocks@2017.
1.1. Run the add-user.sh script.

[student@workstation bin]$ ./add-user.sh -sc /home/student/JB348/labs/\
secure-app/configuration/
1.2. Answer the prompts with the following information:
• The user will be an Application User.
• User name: ralph
• Password: RedHatRocks@2017
• Group: admin
• When prompted about AS processes, the user will not be used to authenticate AS
processes.

Use the following commands to start a standalone EAP instance:

-Djboss.server.base.dir=/home/student/JB348/labs/secure-app
3. Deploy the Secure Application

Deploy the application to the standalone server.
274 JB348-RHJBEAP7-en-6-20170411
3.1. Start the EAP CLI in a new terminal window:

--password=JBoss@RedHat123
3.2. Run the following command in the EAP CLI to deploy the secure application:
[standalone@localhost:9990 /] deploy \
/home/student/JB348/apps/jb348-basic-auth.war
3.3. Access the application by navigating to http://localhost:8080/jb348-basic-

auth in a web browser. Log in with the recently created credentials:
• User name: ralph
• Password: RedHatRocks@2017
Note
A warning about being "Unable to find component" can be safely ignored.
4. Deploy the Form Authentication Secured Application

The application is currently configured for a BASIC authentication, where users are
prompted for authentication immediately upon visiting the application. Many applications,
however, implement a custom form version of authentication because it creates a more user-
friendly experience.
4.1. A separate web application is available in the /home/student/JB348/apps directory,

which is configured for FORM authentication. The only differences between the
two applications are the following excerpt in the web.xml file, and that the BASIC
application points to the other security domain, while the FORM application uses a new
security domain named secure-form:
BASIC authentication:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>file</realm-name>
</login-config>
FORM authentication:
<login-config>
<realm-name>file</realm-name>
<form-login-config>
<form-login-page>/login.xhtml</form-login-page>
<form-error-page>/error.xhtml</form-error-page>
</form-login-config>
JB348-RHJBEAP7-en-6-20170411 275
</login-config>
4.2. Undeploy the BASIC authentication application using the EAP CLI:
[standalone@localhost:9990 /] undeploy jb348-basic-auth.war
5. Add the Data Source

Instead of relying on the application user's property files to manage users, a better practice
in production is to use a database to store user credentials. Add a MySQL data source to use
to store the user credentials for authentication.
5.1. Deploy the MySQL JDBC driver to the standalone instance of EAP using the EAP CLI:
[standalone@localhost:9990] deploy \
/home/student/JB348/installs/mysql-connector-java.jar
Note
If the message 'mysql-connector-java.jar' already exists in
the deployment repository (use --force to replace the
existing content in the repository) is presented, it can be
disregarded.
5.2. Run the following command in a new terminal window to verify that the database is
started and running:
[student@workstation ~]$ sudo systemctl status mariadb
The output should look similar to the following:
mariadb.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/

system/mariadb.service; enabled; vendor preset: disabled) Active: active
(running) since Mon 2016-04-11 08:40:09 EDT; 11h ago
5.3. Connect to the MySQL server with the following credentials:
• User name: jb348
• Password: redhat
[student@workstation ~]$ mysql -ujb348 -predhat
5.4. Use the following command to view the available database:
MariaDB [(none)]> show databases;
5.5. Use the following command to select the jb348 database:
276 JB348-RHJBEAP7-en-6-20170411
MariaDB [(none)]> use jb348;
5.6. Use the following command to list the available tables in the database:
MariaDB [jb348]> show tables;
5.7. Use the following command to see the preconfigured credentials in the users table:
MariaDB [jb348]> select * from users;
5.8. Use the following command to exit the MySQL client:
MariaDB [jb348]> exit;
5.9. Create the data source in the EAP CLI with the following values:
[standalone@localhost:9990 /] data-source add \

--name=jb348 \
--driver-name=mysql-connector-java.jar_com.mysql.jdbc.Driver_5_1 \
--jndi-name=java:jboss/datasources/jb348 \
--connection-url=jdbc:mysql://localhost:3306/jb348 \
--user-name=jb348 --password=redhat
5.10.Test the data source by accessing running the following CLI operation:
[standalone@localhost:9990 /] /subsystem=datasources/data-source=jb348\
:test-connection-in-pool
6. Configure the Database Authentication

The secure form application currently uses the other security domain. Update the domain
to use a database authentication module.
6.1. Run the following command to create the secure-form security domain:
[standalone@localhost:9990 /] /subsystem=security/security-domain=\
secure-form:add(cache-type=default)
Note
Modifying the other security domain is not a best practice because that
security domain is used for other functions within EAP.
6.2. In the EAP CLI, use the following command to create an authentication module:
[standalone@localhost:9990 /] /subsystem=security/security-domain=\
secure-form/authentication=\
JB348-RHJBEAP7-en-6-20170411 277
classic:add
6.3. Access the management console by opening http://localhost:9990 in a web browser

using the following credentials:
• user name: jbossadm
• password: JBoss@RedHat123
Navigate to the management console at http://localhost:9990. Click

Configuration and then Subsystems. Click Security and then click secure-form. Click
View.
6.4. Click Add to add a new authentication module. Use the following values in the dialog
box, and then click Save:
• Name: database
• Code: Database
• Flag: required
6.5. Click Edit under the Attributes header. Enter the following in the Module Options text
area, and then click Save:
dsJndiName=java:jboss/datasources/jb348
principalsQuery=select password from users where username=?
rolesQuery=select role, 'Roles' from roles where username=?
Note
The database login module can be configured from the CLI, however the
command is more prone to typographical errors. It is easier to write in the
management console.
6.6. Reload the server to allow the changes to take place:
[standalone@localhost:9990 /] :reload
6.7. Deploy the FORM authentication application located at /home/student/JB348/

apps/jb348-form-auth.war using the EAP CLI:
[standalone@localhost:9990] deploy /home/student/JB348/apps/jb348-form-auth.war
6.8. Access the application at http://localhost:8080/jb348-form-auth in a web

browser.
6.9. Navigate to the application home page at http://localhost:9990/jb348-form-

auth and log in with the following credentials:
• User name: adminDB
278 JB348-RHJBEAP7-en-6-20170411
• Password: admin
7. Cleanup and Grading

7.1. On workstation run the following command to grade the exercise:
[student@workstation ~]$ lab secure-app grade
7.2. Press Ctrl+C in the terminal window where you started the instance of EAP on
workstation.
JB348-RHJBEAP7-en-6-20170411 279
Defining Role Based Access Control
Objectives
After completing this section, students will be able to implement role-based access control (RBAC).
What is Role-based Access Control?

An important aspect of application security is not only limiting the number of users who can
access an application, but also limiting user privileges based on their role. Application users
who are limited to only their required functions in an application are less likely to make changes
outside of their role, compromise data, or have access to information they do no require. To
provide users with both a safer and more user-friendly application, administrators can implement
RBAC, wherein aspects of an application are restricted based on the user's role.
Authorization
The previous section introduced the concept of authentication of a user to an application. This
refers to verifying the authenticity of a user. Role-based access control is a process of controlling
authorization, or adjusting a user's privileges when accessing an application. Often these
topics are introduced at the same time, because many of the configuration requirements for
authentication and authorization are completed in the same command. For example, the previous
section's exercise used the following database login module to authenticate and authorize users
from a MySQL database:
[standalone@localhost:9990] /subsystem=security/security-domain=other/\
authentication=classic/login-module=database:add( \
code=Database, \
flag=required, \
module-options=[ \
("dsJndiName"=>"java:jboss/datasources/jb348"), \
("principalsQuery"=>"select password from users where username=?"), \
("rolesQuery"=>"select role, 'Roles' from roles where username=?"), \
])
The CLI command to add this login module relies on a data source named java:jboss/
datasources/jb348. To authenticate the user, the login module uses principalsQuery
to find the matching user name and password. The other important query that is executed
is rolesQuery. This query selects the role from the user that is attempting to access the
application. In this instance, a table called Roles contains the user name and its associated role.
280 JB348-RHJBEAP7-en-6-20170411
Authorization
Figure 8.2: A database security domain
For example, many administrators want to restrict administrative tools only to users with the
role admin. To do this using the database login module in EAP, create a table that contains the
user jbossadm and its encrypted password. Create another table, called Roles, that associates
the user jbossadm with the role admin. Update rolesQuery to ensure that the desired role
associated with the user name is selected. This architecture is depicted in Figure 8.2: A database
security domain.
After you have configured the login module and the database, you need to configure security in
the application's web.xml file, and specify the security domain in the jboss-web.xml file. In
the web.xml file, create security constraints that refer by name to the user roles. For example,
to create a restriction on the /secure.xhtml path to only those users with the admin role,
include the following security constraint:
<web-resource-name>Secure resources</web-resource-name>
<url-pattern>/secure.xhtml</url-pattern>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
By using this configuration, any user who does not belong to the admin role is unable to access
the secure.xhtml resource.
JB348-RHJBEAP7-en-6-20170411 281
Similar configurations can be made to manage authorization for external tools, such as LDAP.
Refer to the Red Hat documentation for security for information on integrating with LDAP.
References
Refer to the Security Architecture section in the
EAP 7 documentation
282 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Defining Role Based Access Control
Guided Exercise: Defining Role Based Access

Control
In this exercise, you will configure EAP to block access to users.
Resources
Files: /home/student/JB348/apps/rbac-app.war
Application URL: http://localhost:8080/rbac-app
Outcomes
You will be able to configure RBAC in the secure form application.
Before you begin

/opt/ directory and to download the secure application:
[student@workstation ~]$ lab rbac-app setup

Use the following commands to start a standalone EAP instance:

-Djboss.server.base.dir=/home/student/JB348/labs/rbac-app
2. Evaluate the Security Domain

Check the configuration used by the application.
2.1. Start the EAP CLI in a new terminal window:

2.2. Evaluate the configuration of the security domain used by the application.
From the EAP CLI, run the following command:
[standalone@localhost:9990 /] /subsystem=security/\
security-domain=rbac-app:read-resource(recursive=true)
This command produces a lot of output, but the following configuration output is the
important part:
...
"login-modules" => [{
"code" => "Database",
"flag" => "required",
"module" => undefined,
JB348-RHJBEAP7-en-6-20170411 283
"module-options" => {
"dsJndiName" => "java:jboss/datasources/jb348",
"principalsQuery" => "select password from users where
username=?",
"rolesQuery" => "select role, 'Roles' from roles where
username=?"
}
}],
...
The database used in the previous guided exercise will be used.

Deploy the application to the standalone server.
3.1. Evaluate the application configuration.
In a new terminal window, run the following command to get the contents from the
jboss-web.xml file.
[student@workstation ~]$ unzip -p JB348/apps/rbac-app.war \

WEB-INF/jboss-web.xml
The following output is displayed:
...
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.org/schema/jbossas
http://www.jboss.org/schema/jbossas/jboss-web_7_2.xsd">
<security-domain>java:/jaas/rbac-app</security-domain>
</jboss-web>
The same security domain name is used for the configuration file.
3.2. Evaluate the web.xml configuration file.
In the terminal window, run the following command:
[student@workstation ~]$ unzip -p JB348/apps/rbac-app.war \

WEB-INF/web.xml
The following output is displayed:
<url-pattern>/*</url-pattern>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
<login-config>
284 JB348-RHJBEAP7-en-6-20170411
<realm-name>rbac-app</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
</web-app>
Only the admin user can access these pages.
3.3. Run the following command in the EAP CLI to deploy the secure application:
[standalone@localhost:9990] deploy /home/student/JB348/apps/rbac-app.war
3.4. Navigate to the application home page at http://localhost:8080/rbac-app and

log in with the following credentials:
• Password: admin
A page with the /rbac-app/secure/index.jsp is listed because the adminDB user

belongs to the admin role.
4. Update the Role for the Admin User

4.1. Change the permissions for the user named adminDB, by updating the role from that
user to guest.
Connect to the MySQL server with the following credentials:
• User name: jb348
• Password: redhat
[student@workstation ~]$ mysql -ujb348 -predhat jb348
4.2. Update the permissions of the adminDB user to become part of the guest role.
Run the following command to update the role from the MySQL command line:
MariaDB [jb348]> update roles set role='guest' where username='adminDB';
The following output is expected:
Query OK, 1 row affected (0.01 sec)

Rows matched: 1 Changed: 1 Warnings: 0
4.3. Test the application again by accessing http://localhost:8080/rbac-app/ using

the following credentials:
• Password: admin
JB348-RHJBEAP7-en-6-20170411 285
This time, a Forbidden error is displayed.

[student@workstation ~]$ lab rbac-app grade
5.2. Press Ctrl+C in the terminal window where you started the instance of EAP on
workstation.
286 JB348-RHJBEAP7-en-6-20170411
Securing Applications with Red Hat Identity Management
Securing Applications with Red Hat Identity

Management
Objectives
After completing this section, students will be able to implement single sign-on with Red Hat
Identity Management.
Overview of Red Hat Identity Management

Red Hat Identity Management (IdM) is an integrated identity management service for a wide
range of clients, including a multi-platform environment. It combines lightweight directory access
protocol (LDAP), Kerberos, domain name server (DNS), and a public key infrastructure (PKI) with
a rich management framework. IdM is responsible for:
• Creating a unique and centralized location where all machine and user information is stored.
• Defining access levels for each user to a machine, application, or a service managed by IdM.
• Managing privilege escalation rules.
Benefits of IdM
IdM has some similar features to a generic LDAP provider with additional parameters that allow
authentication systems, such as the system security services daemon (SSSD), to work as a client
of IdM. This approach simplifies the management of identity information and authentication
credentials for users, services, systems, and devices.
Furthermore, any Linux server can be secured with IdM to create a foundation for a highly
dynamic and scalable, cloud and container capable, operational environment. IdM also automates
the deployment of new systems, VMs, and containers with preconfigured identity, authentication,
and access control capabilities. IdM supports SELinux to maximize the security capabilities
needed by an identity management server.
IdM also supports Active Directory native integration that allows Microsoft Windows-based
environment integration.
IdM supports Kerberos ticket management and provides an integrated environment to run
applications in a network. Red Hat Identity Management is provided at no charge with any Red
Hat Enterprise Linux subscription.
Comparing IdM and LDAP

Even though both providers use the same data storage and both can manage authentication and
authorization, IdM has a limited set of capabilities compared to a regular LDAP provider. Red Hat
Identity Manager:
• Stores entries that are LDAP customized entries that are relevant to the identities and
permission management.
• Manages identities within the boundaries of an enterprise or a project, whereas LDAP does not
have these concepts.
• Supports multi-master replication based on the underlying directory server, which guarantees
a high availability environment.
JB348-RHJBEAP7-en-6-20170411 287
• Provides mutual trust with other identity management systems which allows federation
capabilities to any application.
Implementing Kerberos SSO

Kerberos is a network protocol focused on application authentication. It uses secret-key
cryptography (authentication token), which avoids the need to re-authenticate on every desktop
application in a network. IdM can create, distribute, and control these authentication tokens in a
network and all applications running on a network.
For a web application, a Kerberos extension named simple and protected negotiation (SPNEGO) is
responsible for the authentication token negotiation using the web browser.
JBoss Negotiation is a framework responsible for providing JBoss EAP SPNEGO support. It is
provided as a JAAS login module for EAP to connect and negotiate the authentication tokens
with the Kerberos server.
Two security domains must be created:
• Host security domain: Responsible for authenticating the EAP server to the Kerberos server.
The respective login module name is kerberos.
• Application security domain: Uses the authentication from the first security domain (host-
domain) to authenticate users via the SPNEGO login module and a second login module to load
the roles from another provider (a database, for example.)
In the following example, the host security domain is authenticated using a keytab file that holds
the credentials:
<security-domain name="host" cache-type="default">

<authentication>
<login-module code="Kerberos" flag="required">

<module-option name="storeKey" value="true"/>
<module-option name="useKeyTab" value="true"/>
<module-option name="refreshKrb5Config" value="true"/>
<module-option name="keyTab" value="/path/to/krbtgt.keytab"/>

<module-option name="principal" value="HTTP/
primary.example.com@EXAMPLE.COM"/>
<module-option name="doNotPrompt" value="true"/>
<module-option name="debug" value="true"/>
</login-module>
</authentication>
</security-domain>
The Kerberos login module.

The keytab file that holds the credentials for the server. This file is generated by the
Kerberos tool.
The user name and host representing a login for the EAP server.
The authorization for a specific application must use the following security domain:
<security-domain name="app-spnego" cache-type="default">

<authentication>
<login-module code="SPNEGO" flag="required">
<module-option name="serverSecurityDomain" value="host"/>
288 JB348-RHJBEAP7-en-6-20170411
Implementing Kerberos SSO
</login-module>

</authentication>
</security-domain>
The SPNEGO login module.

Reference to the Kerberos login module from the previous setup.
The web application must also be customized to work with the correct approach. Update the
WEB-INF/jboss-web.xml file to include the security domain and valve:
<jboss-web>
<security-domain>java:/jaas/app-spnego</security-domain>
<valve>
<class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
</valve>
</jboss-web>
The class loading structure must be modified to load a module from EAP that supports
SPNEGO. The following configuration must be added to META-INF/jboss-deployment-
structure.xml file to activate the module from EAP 7:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.jboss.security.negotiation"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
References
Red Hat Identity Management website
https://access.redhat.com/products/identity-management
How to implement Kerberos authentication with a Simple REST Web App

https://developer.jboss.org/wiki/
HowToImplementKerberosAuthenticationWithASimpleRESTWebApp
JB348-RHJBEAP7-en-6-20170411 289
Guided Exercise: Secure Applications with SSO
In this exercise, you will manage the Red Hat Identity Management and configure EAP to enable
single sign-on using Kerberos and SPNEGO.
Resources
Files: /home/student/JB348/apps/sso-blue.war /home/
student/JB348/apps/sso-red.war, home/student/
JB348/labs/secure-sso
Application URL: http://workstation:8080/sso-bluehttp://
workstation:8080/sso-red
Outcomes
You will be able to manage the Red Hat Identity Management and configure EAP 7 to
authenticate using Kerberos and SPNEGO.
Before you begin

During this guided exercise, you will configure the environment to enable SSO using Red Hat
Identity Management and the SPNEGO protocol. You will create a new user and authenticate this
user within the operating system using kinit. This authentication will generate a ticket that is
sent by the web browser to all applications that the web browser accesses. The ticket is validated
by JBoss EAP 7, allowing the user to gain access to the application.
On workstation run the following command to verify that an instance of EAP is installed in the
/opt/ directory and to download the required applications:
[student@workstation ~]$ lab secure-sso setup
1. Create new Users

The serverc VM contains an installed and configured instance of Red Hat Identity
Management. Use this server to create the following user:
• Name: Helbert
• Last Name: Rios
• User Login: hrios
• Password: Middleware@2017!
1.1. Open a terminal window on workstation and access serverc using the ssh
command:
[student@workstation ~]$ ssh serverc
1.2. Before creating a new user, log in to Red Hat Identity Management as an administrative
user. Use the following credentials:
• User: admin
290 JB348-RHJBEAP7-en-6-20170411
[student@serverc ~]$ kinit admin
1.3. Use the ipa command to create the new user. When prompted, use
Middleware@2017! as the password:
[student@serverc ~]$ ipa user-add hrios --first=Helbert --last=Rios --password
...
---------------------
Added user "hrios"
---------------------
...
1.4. Authenticate the user with kinit to verify that the user was created correctly.
Every user should change their password when they first authenticate, but for this step
use the same password as the previous step:
[student@serverc ~]$ kinit hrios
2. Create and configure a Service Principal

2.1. Authenticate using the admin user with the password JBoss@RedHat123 to create a
service principal:
Create a new service principal named HTTP/workstation.lab.example.com:
[student@serverc ~]$ ipa service-add HTTP/workstation.lab.example.com
2.2. A keytab file must be generated to connect the EAP 7 instance to IdM.
Connect to the IdM client with the following command:
[student@serverc ~]$ sudo kadmin.local
2.3. Generate the keytab file for the HTTP/workstation.lab.example.com service

principal at /tmp/http.keytab:
Warning
Run the following command on a single line.
JB348-RHJBEAP7-en-6-20170411 291
kadmin.local: ktadd -k /tmp/http.keytab HTTP/

workstation.lab.example.com@LAB.EXAMPLE.COM
2.4. Exit the kadmin.local tool:
kadmin.local: exit

Open a new terminal on workstation and use the following commands to start a
standalone EAP instance:

-Djboss.server.base.dir=/home/student/JB348/labs/secure-sso
4. Configuring EAP 7 to Connect to IdM

4.1. Open a new terminal on workstation and copy the http.keytab keytab file from
serverc to the /home/student/JB348/labs/secure-sso:
[student@workstation ~]$ sudo scp serverc:/tmp/http.keytab \

/home/student/JB348/labs/secure-sso
4.2. Change the owner of the http.keytab file to student:
[student@workstation ~]$ sudo chown student:student /home/student/JB348/labs/\

secure-sso/http.keytab
4.3. Copy the Kerberos configuration client file to the directory /home/student/JB348/
labs/secure-sso:
[student@workstation ~]$ cp /etc/krb5.conf \

/home/student/JB348/labs/secure-sso
4.4. Edit the /home/student/JB348/labs/secure-sso/configure-kerberos.sh

file and update the variables with the following values:
• KEYTAB_FILE: /home/student/JB348/labs/secure-sso/http.keytab
• SERVICE_PRINCIPAL: HTTP/workstation.lab.example.com
• SECURITY_DOMAIN: jb348-sso
• KRB5_CONFIGURATION_FILE: /home/student/JB348/labs/secure-sso/
krb5.conf
4.5. Run the configure-kerberos.sh script to configure Kerberos:
[student@workstation ~]$ cd /home/student/JB348/labs/secure-sso

[student@workstation secure-sso]$ ./configure-kerberos.sh
292 JB348-RHJBEAP7-en-6-20170411
4.6. At this point, EAP 7 can authenticate users against IdM, but it cannot yet authorize
users. Evaluate the /home/student/JB348/labs/secure-sso/configure-
roles.sh script to verify how a role is mapped to a user and run the script:
[student@workstation secure-sso]$ ./configure-roles.sh

5.1. Evaluate the application configuration.
Open a new terminal and run the following command to retrieve the contents from the
jboss-web.xml file.
[student@workstation ~]$ unzip -p JB348/apps/sso-red.war \

WEB-INF/jboss-web.xml
The following output appears:
...
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.org/schema/jbossas
http://www.jboss.org/schema/jbossas/jboss-web_7_2.xsd">
<security-domain>java:/jaas/jb348-sso</security-domain>
<context-root>sso-red</context-root>
</jboss-web>
The same security domain name is used for the configuration file.
5.2. Evaluate the web.xml configuration file.
On workstation, run the following command:
[student@workstation ~]$ unzip -p JB348/apps/sso-red.war \

WEB-INF/web.xml
The following output is listed:
<?xml version="1.0" encoding="UTF-8"?>

<web-app>
<web-resource-name>admin</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<auth-constraint>
<role-name>Admin</role-name>
</auth-constraint>
<security-role>
<description>Role required to log in into admin folders</description>
<role-name>Admin</role-name>
</security-role>
<login-config>
<auth-method>SPNEGO</auth-method>
<realm-name>jb348-sso</realm-name>
JB348-RHJBEAP7-en-6-20170411 293
</login-config>
</web-app>
All the pages under the admin folder are accessible by admin only.
standalone server:

5.4. Run the following command in the EAP CLI to deploy the sso-blue application:
[standalone@172.25.250.254:9990] deploy /home/student/JB348/apps/sso-blue.war
5.5. Run the following command in the EAP CLI to deploy the sso-red application:
[standalone@172.25.250.254:9990] deploy /home/student/JB348/apps/sso-red.war
6. Configure the Web Browser

On workstation, open Firefox and navigate to about:config. Click I'll be careful, I
promise! to configure SPNEGO. Set the following preferences:
• network.negotiate-auth.allow-non-fqdn: true
• network.negotiate-auth.delegation-uris: .lab.example.com
• network.negotiate-auth.trusted-uris: lab.example.com
Warning
Be sure to include the period (.) in front of the network.negotiate-
auth.delegation-uris value.
7. Test the SSO

7.1. Navigate to http://workstation:8080/sso-red. You will see the sso-red
application. Click Navigate to a secure page. A message appears indicating that the
user is unauthorized.
7.2. Open a new terminal on workstation and authenticate the hrios user with the
Middleware@2017! password:
[student@workstation ~]$ kinit hrios
7.3. Refresh the page and see that the authentication works.
7.4. Navigate to http://workstation:8080/sso-blue. You will see the sso-blue

application. Click Navigate to a secure page. Because the user is already authenticated,
you see the secure page.
294 JB348-RHJBEAP7-en-6-20170411
8.1. On workstation, run the following command to grade the exercise:
[student@workstation ~]$ lab secure-sso grade
8.2. Press Ctrl+C in the terminal where you started the instance of EAP on workstation.
JB348-RHJBEAP7-en-6-20170411 295
Lab: Securing Applications
In this lab, you will manage the Red Hat Identity Manager and configure an EAP cluster to enable
Resources
student/JB348/apps/sso-red.war /opt/kerberos
Application URL: http://workstation:8080/sso-blue http://
Outcomes
You will be able to manage the Red Hat Identity Manager and configure an EAP 7 cluster to
Before you begin

During this lab, you will configure the environment to enable SSO using Red Hat Identity
Manager and the SPNEGO protocol. You will create a new user and authenticate this user within
the operating system using kinit. This authentication generates a ticket that is sent by the web
browser to all applications that the web browser accesses. The ticket is validated by JBoss EAP 7,
allowing the user to gain access to the application.
[student@workstation ~]$ lab cluster-sso setup
1. Create new User

The serverc server contains a configured instance of Red Hat Identity Management. Use
this server to create the following user:
• Name: Richard
• Last Name: Painter
• User Login: rpainter
• Password: MyPassword@123
The Red Hat Identity Manager will be configured with the following credentials:
• User: admin

The web browser will access the application using the load balancer, which is available
on workstation. A service principal is required for this load balancer to allow the
authentication. Create a service principal named HTTP/workstation.lab.example.com
and generate a new keytab named lb.keytab. This keytab must be available in the /opt/
kerberos folder on servera and serverb, and owned by the jboss user.
296 JB348-RHJBEAP7-en-6-20170411
Start the load balancer as a standalone instance located on workstation. Use the
following information when starting the load balancer:
• Bind address: 172.25.250.254

With the load balancer up and running, start the domain controller on workstation with
the host-master.xml host configuration file, and set the base directory to /opt/domain.
Start the host controllers on servera and serverb using the host-slave.xml file, and
connect to the domain controller running on 172.25.250.254. Set the base directory
for each to /opt/domain and set the node name to servera or serverb, depending on
5. Prepare the Kerberos Configuration Client

The kerberos client configuration file is required for configuring EAP 7 cluster to connect
to IDM. Copy the /etc/krb5.conf file from workstation to the /opt/kerberos folder
on servera and serverb. The file should be owned by the jboss user.
6. Configure the EAP 7 cluster to Connect to IdM

The /home/student/JB348/labs/cluster-sso/configure-kerberos.sh script
is provided to configure EAP 7 to connect to IdM. Before running the script, update the
variables with the following values:
• KEYTAB_FILE: /opt/kerberos/lb.keytab
• KRB5_CONFIGURATION_FILE: /opt/kerberos/krb5.conf
This script also maps the rpainter user to the Admin role.

Deploy the /home/student/JB348/apps/sso-blue.war and /home/student/JB348/
apps/sso-red.war application to Group1 and Group2 groups.

Configure the web browser to allow SPNEGO authentication.
JB348-RHJBEAP7-en-6-20170411 297
9. Test the SSO

9.2. Open a new terminal window on workstation and authenticate the rpainter user
with the MyPassword@123 password:
[student@workstation ~]$ kinit rpainter

you will see the secure page.

[student@workstation ~]$ lab cluster-sso grade
10.2.Press Ctrl+C in the terminal window where you started the cluster instances of EAP to
stop the cluster.
298 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
In this lab, you will manage the Red Hat Identity Manager and configure an EAP cluster to enable
Resources
student/JB348/apps/sso-red.war /opt/kerberos
Application URL: http://workstation:8080/sso-blue http://
Outcomes
You will be able to manage the Red Hat Identity Manager and configure an EAP 7 cluster to
Before you begin

During this lab, you will configure the environment to enable SSO using Red Hat Identity
Manager and the SPNEGO protocol. You will create a new user and authenticate this user within
the operating system using kinit. This authentication generates a ticket that is sent by the web
browser to all applications that the web browser accesses. The ticket is validated by JBoss EAP 7,
allowing the user to gain access to the application.
[student@workstation ~]$ lab cluster-sso setup
1. Create new User

The serverc server contains a configured instance of Red Hat Identity Management. Use
this server to create the following user:
• Name: Richard
• Last Name: Painter
• User Login: rpainter
• Password: MyPassword@123
The Red Hat Identity Manager will be configured with the following credentials:
• User: admin
1.1. On workstation, open a terminal and access serverc using the ssh command:
[student@workstation ~]$ ssh serverc
1.2. Before creating a new user, log in to Red Hat Identity Manager as admin and use
JBoss@RedHat123 as the password.
JB348-RHJBEAP7-en-6-20170411 299
1.3. Create the user rpainter:
[student@serverc ~]$ ipa user-add rpainter --first=Richard --last=Painter \

--password
1.4. Authenticate the user to confirm that the user was created correctly. Every user should
change their password when they first authenticate. Use the same password:
[student@serverc ~]$ kinit rpainter

The web browser will access the application using the load balancer, which is available
on workstation. A service principal is required for this load balancer to allow the
authentication. Create a service principal named HTTP/workstation.lab.example.com
and generate a new keytab named lb.keytab. This keytab must be available in the /opt/
kerberos folder on servera and serverb, and owned by the jboss user.
2.1. Authenticate using the admin user to create a service principal:
Create a service principal:
[student@serverc ~]$ ipa service-add HTTP/workstation.lab.example.com
2.2. A keytab file must be generated to connect EAP 7 to IdM. Connect to IdM:
[student@serverc ~]$ sudo kadmin.local
2.3.
Warning
Run the previous command on a single line.
Generate the keytab file for the HTTP/workstation.lab.example.com service

principal:
kadmin.local: ktadd -k /tmp/lb.keytab HTTP/

workstation.lab.example.com@LAB.EXAMPLE.COM
2.4. Exit the kadmin.local tool:
kadmin.local: exit
300 JB348-RHJBEAP7-en-6-20170411
Solution
2.5. Copy the keytab file to servera:
[student@serverc ~]$ sudo scp /tmp/lb.keytab servera:/opt/kerberos
Use redhat as the password.
2.6. Copy the keytab file to serverb:
[student@serverc ~]$ sudo scp /tmp/lb.keytab serverb:/opt/kerberos
Use redhat as the password.
2.7. Access servera using the ssh command:
[student@serverc ~]$ ssh servera
Change the keytab file owner to jboss:
[student@servera ~]$ sudo chown jboss:jboss /opt/kerberos/lb.keytab
2.8. Exit servera:
[student@servera ~]$ exit
2.9. Access serverb using the ssh command:
[student@serverc ~]$ ssh serverb
[student@serverb ~]$ sudo chown jboss:jboss /opt/kerberos/lb.keytab
2.10.Exit serverb:
[student@serverb ~]$ exit

Start the load balancer as a standalone instance located on workstation. Use the
following information when starting the load balancer:
• Bind address: 172.25.250.254
JB348-RHJBEAP7-en-6-20170411 301


With the load balancer up and running, start the domain controller on workstation with
the host-master.xml host configuration file, and set the base directory to /opt/domain.
Start the host controllers on servera and serverb using the host-slave.xml file, and
connect to the domain controller running on 172.25.250.254. Set the base directory
for each to /opt/domain and set the node name to servera or serverb, depending on
On workstation:

On servera:

On serverb:

5. Prepare the Kerberos Configuration Client

The kerberos client configuration file is required for configuring EAP 7 cluster to connect
to IDM. Copy the /etc/krb5.conf file from workstation to the /opt/kerberos folder
on servera and serverb. The file should be owned by the jboss user.
5.1. Open a terminal window on workstation and copy the Kerberos client configuration
file to servera:
[student@workstation ~]$ sudo scp /etc/krb5.conf servera:/opt/kerberos
5.2. Copy the Kerberos client configuration file to serverb:
302 JB348-RHJBEAP7-en-6-20170411
Solution
[student@workstation ~]$ sudo scp /etc/krb5.conf serverb:/opt/kerberos
5.3. Access servera using the ssh command:
[student@servera ~]$ sudo chown jboss:jboss /opt/kerberos/krb5.conf
5.4. Exit servera:
[student@servera ~]$ exit
5.5. Access serverb using the ssh command:
[student@serverb ~]$ sudo chown jboss:jboss /opt/kerberos/krb5.conf
5.6. Exit serverb:
[student@serverb ~]$ exit
6. Configure the EAP 7 cluster to Connect to IdM

The /home/student/JB348/labs/cluster-sso/configure-kerberos.sh script
is provided to configure EAP 7 to connect to IdM. Before running the script, update the
variables with the following values:
• KEYTAB_FILE: /opt/kerberos/lb.keytab
• KRB5_CONFIGURATION_FILE: /opt/kerberos/krb5.conf
This script also maps the rpainter user to the Admin role.
6.1. Edit the /home/student/JB348/labs/cluster-sso/configure-kerberos.sh

file and update the variables.
6.2. Run the script to configure Kerberos:
[student@workstation ~]$ cd /home/student/JB348/labs/cluster-sso

[student@workstation cluster-sso]$ ./configure-kerberos.sh
JB348-RHJBEAP7-en-6-20170411 303

Deploy the /home/student/JB348/apps/sso-blue.war and /home/student/JB348/
apps/sso-red.war application to Group1 and Group2 groups.
7.1. On workstation, open a terminal and start the EAP CLI and connect to the domain
controller:

7.2. Run the following command in the EAP CLI to deploy the sso-blue application:
[domain@172.25.250.254:9990] deploy /home/student/JB348/apps/sso-blue.war \

--all-server-groups
7.3. Run the following command in the EAP CLI to deploy the sso-red application:
[domain@172.25.250.254:9990] deploy /home/student/JB348/apps/sso-red.war \

--all-server-groups

Configure the web browser to allow SPNEGO authentication.
On workstation, open Firefox and navigate to about:config. Click I'll be careful, I

promise! to configure SPNEGO. Define the following preferences:
9. Test the SSO

9.2. Open a new terminal window on workstation and authenticate the rpainter user
with the MyPassword@123 password:
[student@workstation ~]$ kinit rpainter

you will see the secure page.

304 JB348-RHJBEAP7-en-6-20170411
Solution
[student@workstation ~]$ lab cluster-sso grade
10.2.Press Ctrl+C in the terminal window where you started the cluster instances of EAP to
stop the cluster.
JB348-RHJBEAP7-en-6-20170411 305
Summary
• A successfully authenticated user is referred to as a principal.
• A security domain is enabled in an application by including the JNDI name of the security
domain in the jboss-web.xml file.
• Role-based access control is a process of controlling the authorization and privileges of a user.
• Red Hat Identity Management is an identity management service that combines LDAP,
Kerberos, DNS, and PKI.
• JBoss Negotiation is a framework responsible for providing JBoss EAP SPNEGO support.
306 JB348-RHJBEAP7-en-6-20170411
TRAINING
CHAPTER 9
SECURING EAP
Overview
Goal Given a properly installed JBoss EAP instance, configure
security settings that include authentication, authorization,
and the management console.
Objectives • Describe strategies for securing EAP.
• Secure the management console.
• Configure management audit logging.
• Deploy a patch to EAP via the management console.
• Describe the ActiveMQ Artemis security features.

Sections • Securing EAP (and Guided Exercise)
• Securing the Management Interface (and Guided Exercise)
• Configure Management Audit Logging (and Guided

Exercise)
• Deploying Patches to EAP (and Guided Exercise)
• Configuring Messaging Security (and Guided Exercise)

Lab • Securing EAP
JB348-RHJBEAP7-en-6-20170411 307
Chapter 9. Securing EAP
Securing EAP
Objectives
After completing this section, students will be able to describe strategies for securing EAP.
Secure EAP
To adequately secure a server, administrators start by looking at the points of entry. Any access
point for a server presents a new vulnerability that needs to be secured and reinforced to
prevent unauthorized access. EAP simplifies its access points by using its host's interfaces and
ports for communication to both the web applications it is serving as well as the management
interfaces. The interfaces and ports are defined in the server configuration files, either
standalone.xml, domain.xml, or host*.xml.
The following is an example of the default settings for the management and public interfaces
that refer to the management and web interfaces, respectively:
<interfaces>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>
</interfaces>
Note
The management and public interfaces can be overwritten by passing in the arguments
-Djboss.bind.address.management and -Djboss.bind.address when
starting the EAP server.
The management console is the main access point for controlling application deployment, server
configurations, and profiles. For this reason, it is important that access to the management
console is not compromised. The following strategies significantly increase the security coverage
of the management console:
1. Restrict the console to run only on the domain controller in a managed domain by disabling
the host controller's access to the management console.
2. Restrict the domain controller's management console to the corporate intranet, preventing
external access.
3. Specify the users and roles that are authorized to access the management console.
4. Configure the management interfaces for HTTPS.
Restricting the Admin Console to the Domain Controller

The management console is configured in the host.xml file for each host. Within the host.xml
file, the default entry for the http-interface looks like the following:
308 JB348-RHJBEAP7-en-6-20170411
Restrict the Domain Controller's Admin Console to the Corporate Intranet
</http-interface>
... Other interfaces ...
</management-interfaces>
Removing this interface disables the management console on any given host. This reduces the
access points for potential intruders and reduces redundancy as the hosts can be managed from
the management console running on the domain controller.
Restrict the Domain Controller's Admin Console to the

Corporate Intranet
The interface used by the management console is defined as part of the http-interface
definition:
</http-interface>
The interface definition in the <interfaces> section of the host.xml file can be updated to
a different inet-address, or users can create new interfaces, such as an interface named
internal-only:
<interfaces>
<interface name="internal-only">
<inet-address value="127.0.0.1"/>
</interface>
</interfaces>
By restricting the inet-address, administrators can have the management interface respond
on any internal network. In addition to using an IP address, users can bind an interface to a
hostname or even a hardware network interface name. The following is a list of possible entries
for the interface:
• <inet-address> is used to provide a particular IP address.
• <nic> is used to bind to a hardware device, regardless of IP: <nic name="lo"/>
• <subnet-match> is used to bind to any address that the machine responds to within a
subnet: <subnet-match value="192.168.0.0/16"/>
Insight
This is particularly useful for restricting communications to an internal address on
Amazon EC2, for instance.
• <any-address/> which binds the interface as a wild card
Configure the Users and Realms That Can Connect to the Server
Users should only be provided as much access as they need to do their job, rather than all
users sharing a Super User account. Users can be created using the EAP_HOME/bin/add-
user.sh script. By specifying the users in the Management Realm, the user is stored in the
JB348-RHJBEAP7-en-6-20170411 309
mgmt-users.properties file with its encrypted password. The management interface is by

default bound to the management realm that is defined in the <security-realms section of
the configuration file:
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local" skip-group-loading="true"/>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization map-groups-to-roles="false">
<properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-
to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-
</authorization>
</security-realm>
</security-realms>
Restricting users access and capabilities based on roles will be discussed later in this chapter.
Demonstration: Binding the Admin Console Interface

1. Run the following command to download the configuration files for this demonstration:
[student@workstation ~] demo admin-interface setup
2. Use the following command to start the domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/admin-interface/machine1/ \
3. Open a web browser on the workstation and navigate to http://localhost:9990 to

verify the management console is accessible.
4. As it is configured now, the management console is running on the same host (localhost) as
the application server. Many production environments would want to separate these two or
have the management console running on a different remote host.
Start the EAP CLI in a new terminal window and connect to the running domain controller:

5. Add a new interface named "console-only". Set the inet-address value to the IP
172.25.252.250, which is the second IP available on eth1. Run the following command:
310 JB348-RHJBEAP7-en-6-20170411
Demonstration: Binding the Admin Console Interface
[domain@localhost:9990 /] /host=master/interface=console-only:\
add(inet-address=172.25.252.250)
6. Update the http-interface by changing the socket interface to console-only:
[domain@localhost:9990 /] /host=master/core-service=management/\
management-interface=http-interface:write-attribute(name=interface,\
value=console-only)
7. Restart the domain controller and verify that the management console can be access by
visiting 172.25.252.250:9990.
[domain@localhost:9990 /]$ /host=master:reload
8. Press Ctrl+C in the terminal windows where you started the domain controller to stop the
managed domain.
JB348-RHJBEAP7-en-6-20170411 311
Guided Exercise: Working with add-user.sh
In this exercise, you will use the add-user.sh script to create and manage a new administrative
user.
Resources
Files: /home/student/JB348/labs/add-user
Application URL: http://localhost:9990
Outcomes
You will be able to create, manage, and disable administrative EAP users.
Before you begin

installed in the /opt/ directory:
[student@workstation ~]$ lab add-user setup

Use the following command to start the domain controller:

-Djboss.domain.base.dir=/home/student/JB348/labs/add-user/machine1/ \
2. Create a New User in the Management Realm

2.1. Run the following command in a new terminal window to start the interactive shell for
creating a new administrative user using the lab directory as the base configuration
directory:

[student@workstation bin]$ ./add-user.sh -dc /home/student/JB348/\
labs/add-user/machine1/configuration/

• The user is a Management User.
• Username: johnqa
• Password: shadowman17!
• Leave the user's group blank.
• The user is in the ManagementRealm.
• When prompted about AS processes, do not set the user to authenticate AS

processes.
312 JB348-RHJBEAP7-en-6-20170411
3. Examine the Contents of the mgmt-users.properties file
Examine the /home/student/JB348/labs/add-user/machine1/configuration/
mgmt-users.properties file, and note that your user has been added to the list of users
with the hashed password.
...
jbossadm=9e9950eb85c96ecc517598b3b7bd897f
johnqa=0d63d85a09b35bc04a7114c55f6fcc37
...
4. Test New User

Access the management console at http://localhost:9990. Use the following new
credentials:
• User name: johnqa
• Password: shadowman17!
5. Comment out the Previous User

5.1. Edit the /home/student/JB348/labs/add-user/machine1/configuration/
mgmt-users.properties file and comment out the jbossadm= line.
...
#jbossadm=9e9950eb85c96ecc517598b3b7bd897f
johnqa=0d63d85a09b35bc04a7114c55f6fcc37
...
5.2. Save the file and log out of the management console. Attempt to log in again with the
following credentials:
Because the user is no longer in the mgmt-users.properties, the management

console does not authenticate.
6. Update Password
6.1. Rerun the add-users script.

labs/add-user/machine1/configuration/
6.2. Answer the prompts with the same information as before, but this time change the
password:
• Username: johnqa
• Update the existing user password and roles.
• Password: middlewarefan1!
JB348-RHJBEAP7-en-6-20170411 313

processes.
6.3. Access the management console at http://localhost:9990 with the updated

password to verify the change:
• User name: johnqa
• Password: middlewarefan1!

[student@workstation ~]$ lab add-user grade
workstation.
314 JB348-RHJBEAP7-en-6-20170411
Securing the Management Interface
Securing the Management Interface
Objectives
After completing this section, students will be able to secure the EAP management interface.
Management Console Security

In previous sections of this course, securing the Management interface has primarily been based
on the network, and the authentication which ships with EAP 7 in the Management Realm. These
are generally sufficient to limit access within a corporate network in cases where the hardware
access is limited to selected administrators. However, when running in a public or private cloud,
for example, users may still need to have access to the Management interfaces from locations
outside a corporate network. Further, there may be teams of administrators in different locations
who all need to access a management interface on a server co-located at an off-site data center,
or similar. In these cases, the management console needs to be both exposed outside of an
internal network, but also tightly secured to prevent unauthorized access.
Removing Silent Authentication

EAP 7 ships with a simple local authentication scheme enabled by default. In the Management
and Application Realms in the standalone.xml and host.xml files, there is the following
entry:
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local"/>
<properties path="mgmt-users.properties" relative-
</authentication>
</security-realm>
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*"/>
<properties path="application-users.properties" relative-
</authentication>
<authorization>
<properties path="application-roles.properties" relative-
</authorization>
</security-realm>
</security-realms>
These entries allow local users to authenticate to the realms without a username and password.
While this setting is convenient in development, it is a security risk in production. To secure
these interfaces from this local access, remove these entries. Be aware that doing so forces all
access to use, at the very least, a username and password to access the server through any
interfaces that are secured with these realms. In addition, the native-interface is used for domain
communications, and by default is secured as part of the Management Realm. Removal of the
local authentication interface requires a username and password to be set up.
Management Interface Ports and Addresses

All management interfaces use a port to define where communications are listened for. By
default, the http-interface (Management Console) uses port 9990, and the native-interface
JB348-RHJBEAP7-en-6-20170411 315
(CLI and Domain communications) uses port 9999. These are configured in the management-
interfaces section of the host.xml or standalone.xml file:
<native-interface>
<socket interface="management" port="${jboss.management.native.port:9999}"/>
</native-interface>
<http-interface>
<socket interface="internal-only" port="${jboss.management.http.port:9990}"/>
</http-interface>
</management-interface>
The interface defines the IP address, Ethernet hardware, or other value, to bind the IP address.
To change the port number, change it through either the management console or the EAP CLI. In
addition, when starting the EAP server, users can alter the port with a system property, such as -
Djboss.management.native.port=19999.
Warning
Changing the jboss.management.native.port value on the domain controller will
require all hosts in a domain to change their value as well. Consider coding this directly
in to the configuration files rather than using the system property at the command line.
Management Interface Security Realm

The management interfaces use the ManagementRealm as their default security realm. However,
it is not required to use this security realm. In many cases, it may be beneficial to replace this
realm, which uses flat files to store passwords (and so requires these password files to be copied
to every host), with a realm which uses LDAP, or some other interface. Other methods include
using a custom JAAS domain for authentication.
Disable JMX Access

Unless JMX access is needed, it is safer to disable it. This avoids opening an additional point of
attack on the EAP server.
The JMX remoting connector is disabled by default in domain mode (though it is enabled
in standalone), and is generally only turned on during development or in some cases where
troubleshooting is needed. A system with the connector enabled has a configuration which looks
like the following:
<subsystem xmlns="urn:jboss:domain:jmx:1.1">
<show-model value="true"/>
<remoting-connector/>
</subsystem>
To remove it, run the following command:
/profile=default/subsystem=jmx/remoting-connector=jmx/:remove
To remove the entire subsystem, run the following command:
/profile=default/subsystem=jmx/:remove
316 JB348-RHJBEAP7-en-6-20170411
Management Console Security
Turn off the Management Console

Users can also completely disable the Management Console (that is, the http-interface). On
managed hosts, such as on servera and serverb, the Management Console is redundant,
since the only Management Console needed is the one on the domain server running on the
workstation. To turn off the Management Console, remove the http-interface entry from
the management-interfaces section of the host.xml file.
A less drastic method is to add the console-enabled attribute to the http-interface and set it to
false:
<http-interface console-enabled="false">
JB348-RHJBEAP7-en-6-20170411 317
Guided Exercise: Implementing Role-based

Security for the Management Interface
In this exercise, you will use the management console to modify the roles of management users.
Resources
Files: /home/student/JB348/labs/role-specific
Outcomes
You will be able to configure management users' roles using the management console.
Before you begin

installed in the /opt/ directory and to download the domain controller base directory:
[student@workstation ~]$ lab role-specific setup


-Djboss.domain.base.dir=/home/student/JB348/labs/role-specific/machine1/ \
2. Enable RBAC
2.1. Use the following command to start the EAP CLI in a new terminal window and to
connect to the domain controller:

2.2. Execute the following command to enable Role-Based Access Control:
[domain@localhost:9990] /core-service=management/access=authorization:\
write-attribute(name=provider, value=rbac)
3. Add admin as a SuperUser

The jbossadm user that is already configured for the management console is not
automatically made a SuperUser once RBAC is enabled.
3.1. In the EAP CLI, execute the following command:
[domain@localhost:9990] /core-service=management/access=authorization/\
role-mapping=SuperUser/include=user-jbossadm:add(name=jbossadm, type=USER)
318 JB348-RHJBEAP7-en-6-20170411
3.2. If the previous command was executed correctly, the CLI generates the following in the
/home/student/JB348/labs/role-specific/machine1/configuration/
domain.xml file:
...
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
<user name="jbossadm"/>
</include>
</role>
</role-mapping>
</access-control>
...
4. In the EAP CLI, run the following command to reload the domain controller:
[domain@localhost:9990] /host=master:reload
5. Add A Monitor User

5.1. Using the add-user.sh script, create a new user with the name monitor and the
password monitor!123. Start the add-user.sh script with the following commands:

labs/role-specific/machine1/configuration/
• Add the user as a Management User.
• Username: monitor
• Password: monitor!123
• Add the user to the ManagementRealm.

processes.
5.3. Access the management console by using a browser to navigate to http://

localhost:9990. Log in with the following credentials:
5.4. Click Access Control at the top of the page. Then click Users in the first column.
5.5. Click Add at the top right of the user list. The Add User dialog appears.
JB348-RHJBEAP7-en-6-20170411 319
Figure 9.1:
The Add User dialog screen.
5.6. Specify the user name as monitor, and select the role Monitor. Leave the other item as
defaults, and click Save.
5.7. Click jbossadm at the top right part of the management console and click Logout. Log
in to the Management console as the user monitor. The user monitor has the role
Monitor, which means that the user can only observe aspects of the management
console without making actual server or management changes. Notice the missing
options such as the ability to make changes in Configuration and the absence of the
Access Control.
6. Add An Operator User

6.1. Using the add-user.sh script, create a new user with the user name operator with
password operator!123. Start the script with the following command:

labs/role-specific/machine1/configuration/

• Add the user as a Management User.
• Username: operator
• Password: operator!123
• When prompted about AS processes, do not set the user as able to authenticate AS
processes.
6.3. Return to the management console, log back in as user jbossadm. Click Access
Control, then click Users.
6.4. Click Add at the top right of the user list. Specify the user name as operator, and
select the role Operator. Leave the other items as defaults, and click Save.
320 JB348-RHJBEAP7-en-6-20170411
6.5. Log out of the management console and log in again as the user operator. The
operator provides some minor access improvements compared to the Monitor users,
such as the ability to control the runtime state of the server. Navigate through the
management console and take notice of the differences.
7. Change Monitor User to Deployer User

7.1. Log back in as jbossadm and click Access Control. Click Roles in the first column.
7.2. Click Deployer in the second column, and under the Membership column click Include.
Click Add, and in the new dialog window, select the user monitor and then click Save.
7.3. In the Role column, click Monitor, the previous role for the monitor user. Click Include
in the Membership column and then click Remove next to the monitor user.
7.4. Log in to the Management console as the user monitor. Now that you have
configured the user monitor to be the role Deployer, the monitor user can modify
configuration and state for deployments. Explore the changes in the management
console that reflect this role.
Note
Disabling the RBAC again will reset all users to the role SuperUser.

[student@workstation ~]$ lab role-specific grade
workstation.
JB348-RHJBEAP7-en-6-20170411 321
Configuring Management Audit Logging
Objectives
After completing this section, students will be able to configure the EAP server for audit logging.
Audit Logging
In addition to managing EAP system users, administrators need to enable oversight of its users,
both as a security measure and as a means of rolling back unintended changes. The management
audit logging feature creates a file that logs each operation enacted on an EAP server and
specifies which user is responsible for the change. The log is also able to distinguish whether
the operation originated from the EAP CLI or the management console. With this information,
administrators and super users are able to roll back an operation that may have compromised
the server as well as discover who is responsible for each management operation executed.
The following is an example log in the audit log:
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "7.0.0.GA",
"user" : "jbossadm",
"domainUUID" : null,
"access" : "NATIVE",
"remote-address" : "127.0.0.1/127.0.0.1",
"success" : true,
"ops" : [{
"address" : [
{
"core-service" : "management"
},
{
"access" : "audit"
},
{
"logger" : "audit-log"
}
],
"operation" : "write-attribute",
"name" : "enabled",
"value" : true,
"operation-headers" : {
"caller-type" : "user",
"access-mechanism" : "NATIVE"
}
}]
From this log, administrators are able to determine that the jbossadm user initiated the
operation. The log also reveals that the operation was NATIVE, and that the operation executed
was enabling the audit-log logger.
In a standalone EAP instance, the audit log configuration is structured as follows:
<audit-log>
<formatters>
322 JB348-RHJBEAP7-en-6-20170411
Enabling Audit Logging in EAP
<json-formatter name="json-formatter"/>
</formatters>
<handlers>
<file-handler name="file" formatter="json-formatter" path="audit-log.log"
relative-to="jboss.server.data.dir"/>
</handlers>
<logger log-boot="true" log-read-only="false" enabled="false">
<handlers>
<handler name="file"/>
</handlers>
</logger>
</audit-log>
Enabling Audit Logging in EAP

By default, the audit logging feature is not enabled. The following EAP CLI command enables
audit logging on a standalone server:
[standalone@localhost /] /core-service=management/access=audit/logger=audit-log:write-
attribute(name=enabled,value=true)
Once enabled, the server begins logging operations to EAP_HOME/standalone/data/audit-

log.log.
In a managed domain, the audit log is enabled on the hosts or on the individual servers. To
enable the audit log on a host, use the following command:
[domain@localhost /] /host=HOST_NAME/core-service=management/access=audit/logger=audit-
log:write-attribute(name=enabled,value=true)
The audit log configured on a host writes operations to EAP_HOME/domain/data/audit-

log.log by default.
To configure the audit log on an individual server, use the following command:
[domain@localhost /] /host=HOST_NAME/core-service=management/access=audit/server-
logger=audit-log:write-attribute(name=enabled,value=true)
Management operations enacted on the server are logged to EAP_HOME/domain/servers/

SERVER_NAME/data/audit-log.log by default.
Management Audit Logging Attributes

The audit log configuration has the following customizable attributes:
Attribute Description
enabled Whether audit logging is enabled.
log-boot Whether operations should be logged on
server boot.
log-read-only Whether operations that do not modify the
configuration or any runtime services should
be logged.
JB348-RHJBEAP7-en-6-20170411 323
In addition to the logger attributes, administrators can change the path and relative-to
attributes to customize the location of the audit log. Set the location of the audit logs in a secure
location.
324 JB348-RHJBEAP7-en-6-20170411
Guided Exercise: Enabling Management Audit Logging
Guided Exercise: Enabling Management Audit

Logging
In this exercise, you will enable audit logging for the management interfaces on a standalone
EAP instance.
Resources
Files: /home/student/JB348/labs/audit-logging
Outcomes
You will be able to enable audit logging for the management interfaces and view the log entries.
Before you begin

[student@workstation ~]$ lab audit-logging setup
1. Start a Standalone EAP Instance

Use the following command to start a standalone EAP instance:

-Djboss.server.base.dir=/home/student/JB348/labs/audit-logging
2. Enabled Management Audit Logging

2.1. In a new terminal window, run the following command to connect to the EAP CLI:

2.2. Run the following command in the EAP CLI to enable standalone server audit logging:
[standalone@localhost:9990 /] /core-service=management/access=audit/\
logger=audit-log:write-attribute(name=enabled,value=true)
{"outcome" => "success"}
3. Examine the Audit Log

By default, the audit log is stored at /home/student/JB348/labs/audit-logging/
data/audit-log.log. Open the log file and view the contents.
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "7.0.0.GA",
"user" : "$local",
"domainUUID" : null,
JB348-RHJBEAP7-en-6-20170411 325
"access" : "NATIVE",
"remote-address" : "127.0.0.1/127.0.0.1",
"success" : true,
"ops" : [{
"address" : [
{
"core-service" : "management"
},
{
"access" : "audit"
},
{
"logger" : "audit-log"
}
],
"name" : "enabled",
"value" : true,
}
}]
The only entry that is present in the log is the CLI command that was run in the previous
step.
4. Modify the Default Deployment Scanner in the Management Console

4.1. Access the management console at http://localhost:9990. Use the following
credentials to access the console:
4.2. Click Configuration, and then click Subsystems. Click Deployment Scanners, and finally
click View next to the subsystem.
4.3. In the attributes for the default deployment scanner, update the Scan enabled attribute
to false to disable hot deployment.
Click Edit and deselect Scan Enabled. Click Save.
4.4. Open the audit log located at /home/student/JB348/labs/audit-logging/

standalone/data/audit-log.log again to view the updated contents. Notice that
the access has changed from NATIVE to HTTP to reflect that the changes were made
via the management console rather than the EAP CLI.
5. Modify the Audit Log Settings

5.1. Use the EAP CLI to enable the audit log to log operations that do not modify the
configuration:
[standalone@localhost:9990] /core-service=management/access=audit/\
logger=audit-log:write-attribute(name=log-read-only, value=true)
5.2. Use the following command to verify that the property was set correctly:
326 JB348-RHJBEAP7-en-6-20170411
[standalone@localhost:9990 /] /core-service=management/access=audit/\
logger=audit-log:read-resource
{
"result" => {
"enabled" => true,
"log-boot" => true,
"log-read-only" => true,
"handler" => {"file" => undefined}
}
}
5.3. Open the audit log and notice that the log now has an entry for the read-resource
command that was executed:
...
"operation" : "read-operation-description",
"name" : "write-attribute",
}
...

[student@workstation ~]$ lab audit-logging grade
on the workstation.
JB348-RHJBEAP7-en-6-20170411 327
Deploying Patches to EAP
Objectives
After completing this section, students will be able to deploy a patch to EAP using the
management console.
Patching EAP
Instead of needing to download and reinstall the entire EAP server, minor updates to EAP are
delivered as patches that can be downloaded from http://access.redhat.com. This makes
it simple to move from version 7.0.0 to 7.0.1 to 7.0.2 of the server. Moving to a new major revision,
however, cannot be accomplished with patching and does require a full reinstall of the server.
JBoss patches are delivered via zip and RPM files. If the server is not initially installed with an
RPM file, then RPM patches cannot be used. Additionally, if the server is installed with an RPM,
then ZIP patches cannot be used.
Patches are generally issued for one of two cases:

1. Planned updates, which include cumulative updates.
2. Asynchronous updates, which are generally security patches or patches issued by Red Hat
Global Support Services to fix a specific issue.
Patches are applied by adding an overlay to the modules directory under the EAP install
directory, such as $EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/
$MODULE. While the original jars and module remain on the system, they are disabled by altering
the original jar to be unusable. This process is reversible, in case a rollback of a patch is required.
Installing a Patch with the CLI

Download the patch ZIP file from https://access.redhat.com/ that corresponds to the
major version of EAP being used.
The EAP CLI tool provides the patch command to access the patch management system from
the command line. The primary options are:
• apply to apply the patch zip
• info to get information about the currently installed patches
• history to get information about the patching history
• rollback to undo a patch
For example, to apply a patch to a server, log in via the EAP CLI and run:
[standalone@localhost:9999 /] patch apply /path/to/jboss-eap-7.0.1-patch.zip
After installing the patch, the server must be restarted.
Installing a Patch with the Management Console

The Management Console allows patching of all hosts in a domain through a single interface as
well as standalone server instances. Once logged in, click the Patching tab, select the host to be
patched.
328 JB348-RHJBEAP7-en-6-20170411
Patching EAP
Figure 9.2:
Patch Management Screen
From this screen, click Apply a New Patch, upload the patch and then restart the server.
References
Patching and Upgrading Guide
red_hat_jboss_enterprise_application_platform/7.0/html-single/
patching_and_upgrading_guide/
JB348-RHJBEAP7-en-6-20170411 329
Guided Exercise: Installing a Patch
In this exercise, you will apply a patch to an instance of EAP.
Resources
Files: /home/student/JB348/labs/patch-eap
Outcomes
You will be able to enable audit logging for the management interfaces and view the log entries.
Before you begin

[student@workstation ~]$ lab patch-eap setup
1. Back Up EAP 7.0 Installation

1.1. In a terminal window, run the following commands to copy the /opt/jboss-eap-7.0
directory and rename it /opt/jboss-eap-7.0.4:
[student@workstation ~]$ cd /opt

[student@workstation opt]$ sudo cp -r jboss-eap-7.0/ jboss-eap-7.0.4/
1.2. Update the new directory to have the same owner as the previous install of EAP:
[student@workstation opt]$ sudo chown -R jboss:jboss jboss-eap-7.0.4

[student@workstation opt]$ cd /opt/jboss-eap-7.0.4/bin

3. Patch the Master Host

3.1. Access the management console by visiting http://localhost:9990, using the
following credentials:
3.2. At the top of the screen, click Patching.
3.3. In the master row in the Host table, click View under the Option column.
3.4. On the Patch Management page, click Apply a New Patch.
3.5. In the dialog window titled Apply a Patch, click Browse and navigate to /home/
student/JB348/installs/jboss-eap-7.0.4-patch.zip. Click Next.
330 JB348-RHJBEAP7-en-6-20170411
3.6. When prompted to restart the server, click Restart servers now.
3.7. The Apply a Patch dialog displays Patch successfully applied!. Ensure that Yes
restart the host now is selected and click Finish.
4. Verify the Patch

Return to the server output in the terminal and look for the following line to confirm that
EAP 7 is patched with update 7.0.4:

WFLYSRV0025: JBoss EAP 7.0.4.GA (WildFly Core 2.1.10.Final-redhat-1) (Host
Controller) started in 4664ms - Started 52 of 52 services (15 services are lazy,
passive or on-demand)
5. Use the CLI to Roll Back the Patch

The CLI can be used to patch and roll back patches to EAP. Use the CLI to roll back the
7.0.4 patch.
5.1. Use the following command to connect to the EAP CLI in a new terminal window:
[student@serverb ~]$ cd /opt/jboss-eap-7.0.4/bin

[student@serverb ~]$ ./jboss-cli.sh -c
Note
The warning about the JBOSS_HOME variable can be safely ignored.
5.2. Use the patch history command to see a list of patches applied on the connected
EAP instance:
[domain@localhost:9990 /] patch history --host=master
5.3. Use the following command to roll back the patch:
[domain@localhost:9990 /] patch rollback --patch-id=jboss-eap-7.0.4.CP \

--host=master --reset-configuration=TRUE
5.4. Restart the JBoss EAP instance with the following command:
[domain@localhost:9990 /] shutdown --restart=true --host=master
5.5. Return to the server log and look for the following output to confirm that the patch was
rolled back:

WFLYSRV0025: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) (Host
Controller) started in 3154ms - Started 52 of 52 services (15 services are
lazy, passive or on-demand)
JB348-RHJBEAP7-en-6-20170411 331

[student@workstation ~]$ lab patch-eap grade
6.2. Press Ctrl+C in the terminal window where you started the instance of EAP on the
workstation.
332 JB348-RHJBEAP7-en-6-20170411
Configuring Messaging Security
Configuring Messaging Security
Objectives
After completing this section, students will be able to secure aspects of ActiveMQ Artemis
messaging subsystem.
Secure ActiveMQ Artemis

Administrators need to be diligent about securing the messaging subsystem to prevent unwanted
users from managing, sending, or receiving messages from messaging queues. Within EAP 7, the
ActiveMQ Artemis subsystem configuration provides simple ways to integrate with both the EAP
security domains and realms that are already used to secure the application server. There are
two ways a client can be authenticated:
• Connection
The client can pass username and password when the connection to the server is created.
• Security Context
The credentials are passed as part of the JBoss security context. Typically this is done from a
web or EJB client where authentication has already occurred.
Authentication works the same way as other components of JBoss EAP. A security domain
is established. This dictates how authentication (and potentially authorization) is dealt with.
By default, the other security domain is configured to be the ActiveMQ subsystem's security
domain. This configuration is not explicitly stated in the configuration files, but it can be seen
using the following command in the EAP CLI:
[standalone@localhost /] /subsystem=messaging-activemq/server=default:read-
attribute(name=security-domain)
{
"result" => "other"
}
This value can also be changed if administrators prefer to use a new or different security domain.
This can be achieved with the following command:
[standalone@localhost /]
/subsystem=messaging-activemq/server=default:write-attribute(name=security-domain,
value=DomainName)
You can turn security off by setting security-enabled to false. This is not secure and is not
recommended.
Authorization
Authorization is the process of granting or denying an operation on an ActiveMQ Artemis
resource based on roles that are held by the authenticated user and the permission rules
that are defined for that resource. When authentication occurs, a series of roles are passed
along with the authentication token. In the out of the box configuration, roles are stored in the
application-roles.properties file. The following permissions are provided:
JB348-RHJBEAP7-en-6-20170411 333
• consume
Read messages from a queue.
• create-durable-queue
Programmatically create a queue with <durable>true</durable>.
• create-non-durable-queue
Programmatically create a queue with <durable>false</durable>.
• delete-durable-queue
Programmatically delete a queue with <durable>true</durable>.
• delete-non-durable-queue
Programmatically delete a queue with <durable>false</durable>.
• manage
Allows programmatic invocation of the ActiveMQ management operations. These are accessed
by sending messages to the management address.
• send
Send a message to a queue.
Authorization configuration is done in the <security-setting> element in the messaging

subsystem:
...
<security-settings>
<role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true"
consume="true" send="true"/>
</security-setting>
</security-settings>
...
The role refers to a role that is being granted or restricted permissions on queues or topics that
match the "name" filter.
If an address matches more than one security setting, the more specific match is selected.
Securing the Transport

By default, the http-connector is convenient and easy to use, however it needs further
configuration in order to be properly secured. By enabling normal web traffic to use SSL
to encrypt the traffic from the connector to the acceptor, the messaging transport can be
adequately secured.
ActiveMQ Artemis uses client certificates to secure transports on remote connectors. Users
must provide the connector on the client side with a keystore containing the client certificate, the
server with its keystore, and a truststore containing the client certificates that it will accept.
334 JB348-RHJBEAP7-en-6-20170411
Securing the Transport
Note
A very good article on setting up server and client keystore and truststores can
be found at http://www.ibm.com/developerworks/java/library/j-
customssl/sidebar.html.
In order to secure a remote connector, users must create a remote-acceptor, and a remote-
connector. Use the following EAP CLI command to create a remote-connector that passes in
the path to the key store as well as the key store password:
/subsystem=messaging-activemq/server=default/remote-acceptor=mySslAcceptor:add\
(socket-binding=netty,params={ssl-enabled=true,
key-store-path=path/to/server.jks, \
key-store-password=${VAULT::server-key::key-store-password::sharedKey}})
The following command creates the complimentary remote-connector:
/subsystem=messaging-activemq/server=default/remote-connector=mySslConnector:add\
(socket-binding=netty,params={ssl-enabled=true})
Because each client could theoretically store the trust store at different locations and be
encrypted by different passwords, it is not recommended to pass in the trust-store-path
and trust-store-password in the remote-connector. Instead, administrators can
configure these as system properties using the property javax.net.ssl.trustStore and
javax.net.ssl.trustStorePassword. If, however, the remote-connector is being used
to connect to another server, then the trust store parameters should be set in the remote-
connector.
References
Configuring Messaging
red_hat_jboss_enterprise_application_platform/7.0/html-single/
configuring_messaging/#configuring_messaging_security
JB348-RHJBEAP7-en-6-20170411 335
Guided Exercise: Configuring Messaging

Security
In this exercise, you will secure messaging queues in an EAP instance.
Resources
Files: /home/student/JB348/labs/secure-messaging
Outcomes
You will be able to secure the messaging subsystem.
Before you begin

[student@workstation ~]$ lab secure-messaging setup

The setup script for this guided exercise downloaded files for a preconfigured Standalone
server.
Open a new terminal window on workstation and run the following command to start the
Standalone server:

-Djboss.server.base.dir=/home/student/JB348/labs/secure-messaging/machine1/

The development team has created a new application that requires the use of the messaging
technology. Create a new queue with the following characteristics:
• Queue Name: ProjectQueue
• JNDI Name: java:/jboss/exported/jms/queue/ProjectQueue
• Persistence: No
2.1. Open a new terminal window from the workstation VM and connect to CLI to create
the queue:

336 JB348-RHJBEAP7-en-6-20170411
--queue-address=ProjectQueue --durable=false \
3. Configure Roles
3.1. Create a new security setting for the ProjectQueue queue.
[standalone@172.25.250.254:9990 /] /subsystem=messaging-activemq/server\
=default/security-setting=jms.queue.ProjectQueue:add()
3.2. For the role queueUser, give the users permission to create and delete non-durable
queues, and consume and send messages, with the following command:
=default/security-setting=jms.queue.ProjectQueue/\
role=queueUser:add(consume=true,\
delete-non-durable-queue=true,create-non-durable-queue=true,send=true)
3.3. Add another role that is slightly more restrictive. For the tester role, only provide the
users in that role the capability to send messages.
=default/security-setting=jms.queue.ProjectQueue/role=tester:add(consume=false,\
delete-non-durable-queue=false,create-non-durable-queue=false,send=true)
3.4. Run the following command to verify that the security settings are correctly configured:
=default/security-setting=jms.queue.ProjectQueue/:read-resource(recursive=true)
{
"result" => {"role" => {
"queueUser" => {
"consume" => true,
"create-durable-queue" => false,
"create-non-durable-queue" => true,
"delete-durable-queue" => false,
"delete-non-durable-queue" => true,
"manage" => false,
"send" => true
},
"tester" => {
"consume" => false,
"create-durable-queue" => false,
"create-non-durable-queue" => false,
"delete-durable-queue" => false,
"delete-non-durable-queue" => false,
"manage" => false,
"send" => true
}
}}
}
JB348-RHJBEAP7-en-6-20170411 337
4. Add User and Roles

With the security settings configured for the queueUser and tester roles, create new
users to attach to these roles.
4.1. Exit the EAP CLI and run the /opt/jboss-eap-7.0/bin/add-user.sh script.
[standalone@172.25.250.254:9990 /] exit
labs/secure-messaging/machine1/configuration/
4.2. Use the following information in the add-user.sh prompts:
• Create the user as an Application User.
• Username: johnAdmin
• Group: queueUser
• When prompted about AS processes, do not enable the user to authenticate AS

processes.
4.3. Run the script again, but this time use the following values for the tester role.
• Create the user as an Application User.
• Username: contractor
• Password: MiddlewareFan1!
• Group: tester
• When prompted about AS processes, do not enable the user to authenticate AS

processes.
4.4. Examine the /home/student/JB348/labs/secure-messaging/machine1/

configuration/application-roles.properties file to verify the users have
been attached to the roles correctly:
...
johnAdmin=queueUser
contractor=tester
5. Test the New Queue

5.1. The message-client.jar application is provided to test the queue. Run the
application, passing the send argument with the contractor user created in the
previous step. This sends one message to the ProjectQueue queue. The output reads
"Message sent". If there are errors, fix them until the example reports success.
[student@workstation bin]$ cd /home/student/JB348/apps

send --user=contractor --password=MiddlewareFan1!
338 JB348-RHJBEAP7-en-6-20170411
5.2. Run the application again, using the receive argument. This takes one message off the
ProjectQueue queue. Because the user does not have read access, the receive should
fail with an error "User: contractor does not have permission='CONSUME'".

receive --user=contractor --password=MiddlewareFan1!
5.3. Run the application again with the receive argument. This time, use the user
johnAdmin, who is able to read from the queues:

receive --user=johnAdmin --password=JBoss@RedHat123
You are presented with the following output:
Message is: hello

[student@workstation ~]$ lab secure-messaging grade
on the workstation.
JB348-RHJBEAP7-en-6-20170411 339
Lab: Securing EAP
In this lab, you will secure the EAP server and manage administrative users.
Resources
Files: /opt/domain/
Application URL: http://172.25.250.254:9990
Outcomes
You will be able to secure the EAP server and prevent unauthorized users from making changes
to the server.
Before you begin

necessary lab files:
[student@workstation ~]$ lab secure-lab setup
A developer in your organization mentioned that there appears to be unusual events appearing
the EAP server logs. Start up the managed domain, use the audit log to diagnose the issue,
resolve the issue, and then make necessary security adjustments to prevent unauthorized users
from making server configuration changes.

domain controller:

1.2. Open a new terminal window and run the following command on servera to start the

1.3. Open a new terminal window and run the following command on serverb to start the

340 JB348-RHJBEAP7-en-6-20170411
2. Analyze the Audit Logs

The server logs are printing far more information than is necessary. Check the audit log on
the workstation VM to see which user made changes to the logging subsystem, and which
changes were made. Reset the logging subsystem back to the default INFO levels for the
affected logger and handler.
3. Enable Audit Logging on Hosts

With the logging issue resolved, your managers have decided that it is time to start
tightening up EAP security to prevent unexpected changes from being made by users.
Enable audit logging on the servera and serverb host.
4. Enable Role Based Access

User steve was able to make server configuration changes, but he should only be
responsible for deploying applications. Enable Role Based Access, setting jbossadm user as
a Super User, and then configure user steve to have the role Deployer.

[student@workstation ~]$ lab secure-lab grade
JB348-RHJBEAP7-en-6-20170411 341
Solution
In this lab, you will secure the EAP server and manage administrative users.
Resources
Files: /opt/domain/
Application URL: http://172.25.250.254:9990
Outcomes
You will be able to secure the EAP server and prevent unauthorized users from making changes
to the server.
Before you begin

necessary lab files:
[student@workstation ~]$ lab secure-lab setup
A developer in your organization mentioned that there appears to be unusual events appearing
the EAP server logs. Start up the managed domain, use the audit log to diagnose the issue,
resolve the issue, and then make necessary security adjustments to prevent unauthorized users
from making server configuration changes.

domain controller:

1.2. Open a new terminal window and run the following command on servera to start the

1.3. Open a new terminal window and run the following command on serverb to start the

342 JB348-RHJBEAP7-en-6-20170411
Solution
2. Analyze the Audit Logs

The server logs are printing far more information than is necessary. Check the audit log on
the workstation VM to see which user made changes to the logging subsystem, and which
changes were made. Reset the logging subsystem back to the default INFO levels for the
affected logger and handler.
2.1. Open the archived audit log file at /opt/domain/data/audit-log.log* on

workstation.
Note
The audit-log.log* file has a specific time code and date appended to the
end of the name.
2.2. The log contains the following two entries, indicating that user steve adjusted both the
CONSOLE handler and the ROOT logger:
2017-02-28 14:36:09 - {
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "7.0.0.GA",
"user" : "steve",
"domainUUID" : "ff41f38c-5dae-441a-b1bb-66c02b5846c0",
"access" : "HTTP",
"remote-address" : "127.0.0.1/127.0.0.1",
"success" : true,
"ops" : [{
"operation" : "composite",
"address" : [],
"steps" : [{
"address" : [
{
"profile" : "full-ha"
},
{
"subsystem" : "logging"
},
{
"console-handler" : "CONSOLE"
}
],
"name" : "level",
"value" : "ALL"
}],
"operation-headers" : {"access-mechanism" : "HTTP"}
}]
}
2017-02-28 14:36:09 - {
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "7.0.0.GA",
"user" : "steve",
"domainUUID" : "ff41f38c-5dae-441a-b1bb-66c02b5846c0",
"access" : "HTTP",
"remote-address" : "127.0.0.1/127.0.0.1",
JB348-RHJBEAP7-en-6-20170411 343
"success" : true,
"ops" : [{
"address" : [],
"steps" : [{
"address" : [
{
},
{
},
{
"console-handler" : "CONSOLE"
}
],
"name" : "level",
"value" : "ALL"
}],
}]
}
2017-02-28 14:36:21 - {
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "7.0.0.GA",
"user" : "steve",
"domainUUID" : "037fc5bd-870d-42a5-a409-5ffb7928f1e3",
"access" : "HTTP",
"remote-address" : "127.0.0.1/127.0.0.1",
"success" : true,
"ops" : [{
"address" : [],
"steps" : [{
"address" : [
{
},
{
},
{
"root-logger" : "ROOT"
}
],
"name" : "level",
"value" : "ALL"
}],
}]
}
2.3. On the workstation, use a web browser to navigate to the domain master
management console at http://172.25.250.254:9990. Log in with the following
credentials:
344 JB348-RHJBEAP7-en-6-20170411
Solution
2.4. Click Configuration at the top of the page, and then click Profiles in the first column and
then full-ha in the second column.
2.5. In the subsystem column, click Logging and then click View.
2.6. Under the Root Logger tab, click Edit. Change the Level from ALL to INFO. Click Save.
2.7. Click Handler and then click Edit. Change the Level from ALL to INFO. Click Save. The
server logging is now set back to its defaults.
3. Enable Audit Logging on Hosts

With the logging issue resolved, your managers have decided that it is time to start
tightening up EAP security to prevent unexpected changes from being made by users.
Enable audit logging on the servera and serverb host.
3.1. On the workstation, connect to the EAP CLI:

[student@workstation ~]$ ./jboss-cli.sh -c --controller=172.25.250.254:9990
3.2. Run the following command to enable audit logging on the servera host:
[domain@172.25.250.254:9990 /] /host=servera/core-service=management/\
access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
3.3. Run the following command to enable audit logging on the serverb host:
[domain@172.25.250.254:9990 /] /host=serverb/core-service=management/\
access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
4. Enable Role Based Access

User steve was able to make server configuration changes, but he should only be
responsible for deploying applications. Enable Role Based Access, setting jbossadm user as
a Super User, and then configure user steve to have the role Deployer.
4.1. Run the following command to enable Role Based Access in a managed domain:
[domain@172.25.250.254:9990 /] /core-service=management/access=authorization\
:write-attribute(name=provider,value=rbac)
4.2. Set the jbossadm user as a Super User:
[domain@172.25.250.254:9990 /] /core-service=management/access=authorization/\
role-mapping=SuperUser/include=user-jbossadm:add(name=jbossadm, type=USER)
4.3. Reload the master host for the changes to take effect:
[domain@172.25.250.254:9990 /] /host=master:reload
4.4. Reload servera and serverb:
JB348-RHJBEAP7-en-6-20170411 345
4.5. Access the management console by using a browser to navigate to

http://172.25.250.254:9990. Log in with these credentials:
4.6. Click Access Control at the top of the page. Click Users in the first column.
4.7. Click Add at the top right of the user list. The Add User dialog appears.
4.8. Specify the user name as steve, and select the role Deployer. Leave the other item as
its default value and click Save.

[student@workstation ~]$ lab secure-lab grade
346 JB348-RHJBEAP7-en-6-20170411
Summary
Summary
• Removing access to the management console from host controllers improves the server
security my reducing access points.
• Restricting the management interface to an internal intranet prevents external users from
being able to attempt to access the management console.
• The management interfaces use the ManagementRealm as the default security realm. This
can be replaced with a custom realm that uses LDAP or another interface.
• Enabling audit logging on a server provides a detailed list of all actions that change the server
configuration.
• EAP patches are installed either with the management console or with the EAP CLI.
• Configuring security authorization is done in the security-settings value in the

messaging subsystem.
JB348-RHJBEAP7-en-6-20170411 347
348
TRAINING
CHAPTER 10
COMPREHENSIVE REVIEW:
RED HAT JBOSS APPLICATION
ADMINISTRATION II
Overview
Goal Review tasks from Red Hat JBoss Application Administration
II
Objective Review tasks from Red Hat JBoss Application Administration
II
Section Comprehensive Review
Lab • Lab: Comprehensive Review Part 1
• Lab: Comprehensive Review Part 2
JB348-RHJBEAP7-en-6-20170411 349
Chapter 10. Comprehensive Review: Red Hat JBoss Application Administration II
Comprehensive Review
Objectives
After completing this section, students will review and refresh knowledge and skills learned in
Red Hat JBoss Application Administration II .
Reviewing Red Hat JBoss Application Administration

II
Before beginning the comprehensive review for this course, students should be comfortable with
the topics covered in each chapter.
The review is split into three different labs and each part covers various topics and objectives.
The sections can be completed in any order.
Students can refer to earlier sections in the textbook for extra study.
Chapter 10, Comprehensive Review: Red Hat JBoss Application Administration II

350 JB348-RHJBEAP7-en-6-20170411
Lab: Comprehensive Review Part One
Lab: Comprehensive Review Part One
In this review, you will gain access to an EAP Cluster and debug clustering, messaging, and
Infinispan errors.
Outcomes
You should be able to:
• Access an EAP server without credentials.
• Resolve a JGroups clustering problem.
• Configure the messaging subsystem.
Before you begin

Log in to workstation as student and run the following command to set up your VMs for this
exercise:
[student@workstation ~]$ lab review1 setup
Instructions
You have inherited an EAP managed domain that contains a domain controller, two host
controllers, and two servers on each host controller. The following diagram reflects the
architecture of the managed domain:
JB348-RHJBEAP7-en-6-20170411 351
Figure 10.1: Domain Topology
The environment is based on three virtual machines running Red Hat Enterprise Linux 7
(RHEL 7) with a minimal set of tools installed, including Java 8:
workstation VM (IP: 172.25.254.250)

The only VM with a graphical interface installed. It hosts EAP running a standalone server
and a domain controller. The standalone server is responsible for load balancing requests.
servera VM (IP: 172.25.254.10)

A text-based VM responsible for running multiple EAP instances managed by the domain
controller installed at the workstation.
serverb VM (IP: 172.25.254.11)

To access each VM, you are provided with the following credentials:
• login: student
• password: student
On each VM, EAP is installed at /opt/jboss-eap-7.0 and the base directory for the server
configuration is /opt/domain.
352 JB348-RHJBEAP7-en-6-20170411
Instructions
Complete the following tasks in order:
1. The previous administrator forgot to leave the password for the administration account.
Gain access to the server located at /opt/domain by creating a jbossadmin user and
with Middleware@2017! as the password. Start the load balancer and managed domain
based on the architecture diagram using /opt/domain as a base directory for the domain
controller and host controller and /opt/lb for the load balancer on workstation. The
load balancer must run with a port offset of 1000 and use the standalone-ha.xml
configuration file. Verify that you can access the server by logging in to the management
console at http://172.25.250.254:9990.
2. There are reports that the application is not correctly clustering. Access the Cluster
application and determine that the application is not clustering correctly because the
counter is not persisting in a clustered manner. Fix the broken clustering and retest to verify
that the sessions are persisting in the cluster.war application.
Note
Hint: Look at the JGroups configuration.
3. The previous administrator left before configuring the messaging system. Satisfy the client
requirements by completing the following tasks:
3.1. Create a new persistent queue called LabQueue with the JNDI name java:/jboss/
exported/jms/queue/LabQueue.
3.2. Create an Expiry Queue with the name LabQueueEXQ and the JNDI name java:/
jboss/exported/jms/queue/LabQueueEXQ that is not persistent.
3.3. Create a DLQ with the name LabQueueDLQ and the JNDI name java:/jboss/
exported/jms/queue/LabQueueDLQ that is not persistent. The DLQ should be set
as the DLQ for the previously created queue LabQueue and should have a maximum
delivery attempts set to 3.
3.4. Configure message persistence by setting the journal file size to 65536 and configure
the minimum number of files that make up the message journal to 5.
3.5. For testing, a new credential must be created with the following properties to send
and receive messages on both servera and serverb with the name lab-user and
password Lab@JMS59! in the group guest.
3.6. The /home/student/JB348/apps/messaging-client.jar application is

provided to test the queue. Use the argument labsend to send messages and
labdrain to drain messages. Send 100 messages to the queue, passing the following
parameters:
• --password: Lab@JMS59!
JB348-RHJBEAP7-en-6-20170411 353
3.7. The messages are still not properly load-balanced. Configure the subsystem so that the
messages strictly balance to ensure one server is not handling all of the load. Retest
sending messages to verify that the load is properly balanced.
Steps
Evaluation
As the student user on workstation, run the lab review1 grade script to confirm success
on this exercise. Correct any reported failures and rerun the script until successful.
[student@workstation ~]$ lab review1 grade
354 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
In this review, you will gain access to an EAP Cluster and debug clustering, messaging, and
Infinispan errors.
Outcomes
• Access an EAP server without credentials.
• Resolve a JGroups clustering problem.
• Configure the messaging subsystem.
Before you begin

exercise:
Instructions
You have inherited an EAP managed domain that contains a domain controller, two host
controllers, and two servers on each host controller. The following diagram reflects the
architecture of the managed domain:
JB348-RHJBEAP7-en-6-20170411 355
Figure Error.1: Domain Topology

The only VM with a graphical interface installed. It hosts EAP running a standalone server
and a domain controller. The standalone server is responsible for load balancing requests.
servera VM (IP: 172.25.254.10)

serverb VM (IP: 172.25.254.11)

• login: student
1. The previous administrator forgot to leave the password for the administration account.
Gain access to the server located at /opt/domain by creating a jbossadmin user and
with Middleware@2017! as the password. Start the load balancer and managed domain
based on the architecture diagram using /opt/domain as a base directory for the domain
controller and host controller and /opt/lb for the load balancer on workstation. The
load balancer must run with a port offset of 1000 and use the standalone-ha.xml
configuration file. Verify that you can access the server by logging in to the management
console at http://172.25.250.254:9990.
2. There are reports that the application is not correctly clustering. Access the Cluster
application and determine that the application is not clustering correctly because the
counter is not persisting in a clustered manner. Fix the broken clustering and retest to verify
that the sessions are persisting in the cluster.war application.
Note
Hint: Look at the JGroups configuration.
3.1. Create a new persistent queue called LabQueue with the JNDI name java:/jboss/
356 JB348-RHJBEAP7-en-6-20170411
Instructions
3.2. Create an Expiry Queue with the name LabQueueEXQ and the JNDI name java:/
jboss/exported/jms/queue/LabQueueEXQ that is not persistent.
3.3. Create a DLQ with the name LabQueueDLQ and the JNDI name java:/jboss/
exported/jms/queue/LabQueueDLQ that is not persistent. The DLQ should be set
as the DLQ for the previously created queue LabQueue and should have a maximum
delivery attempts set to 3.
3.4. Configure message persistence by setting the journal file size to 65536 and configure
the minimum number of files that make up the message journal to 5.
3.5. For testing, a new credential must be created with the following properties to send
and receive messages on both servera and serverb with the name lab-user and
password Lab@JMS59! in the group guest.
3.6. The /home/student/JB348/apps/messaging-client.jar application is

provided to test the queue. Use the argument labsend to send messages and
labdrain to drain messages. Send 100 messages to the queue, passing the following
parameters:
3.7. The messages are still not properly load-balanced. Configure the subsystem so that the
Steps
1. Before you can make any meaningful changes to the server, you need access to the
management interface. Create a jbossadmin user with Middleware@2017! as the
password. Start the load balancer and managed domain based on the architecture diagram
using /opt/domain as a base directory for the domain controller and host controller and
/opt/lb for the load balancer on workstation. The load balancer must run with a port
offset of 1000 and use the standalone-ha.xml configuration file.
Verify that you can access the server by logging in to the management console at
http://172.25.250.254:9990.
1.1. Run the following command in a new terminal window to start the interactive
shell. Create a new administrative user, using the /opt/domain folder as the base
configuration directory:

[student@workstation bin]$ sudo -u jboss ./add-user.sh \
-dc /opt/domain/configuration
• The user is a Management User.
JB348-RHJBEAP7-en-6-20170411 357
• User name: jbossadmin
• Password: Middleware@2017!
• Enter yes when prompted about connecting to the master.
1.3. Copy the <secret value> tag from the output. You will add this to the host
controllers later.
To represent the user add the following to the server-identities definition

<secret value="TwlkZGxld2FyZUAyMDE3IQ==" />
1.4. Run the following command to start the domain controller using the /opt/domain/
host-master.xml file:

1.5. Connect to servera and edit the /opt/domain/configuration/host-slave.xml

file.

[student@servera ~]$ cd /opt/domain/configuration
[student@servera ~]$ sudo -u jboss vi host-slave.xml
1.6. Update the <secret value> tag to contain the new generated value.
...
<server-identities>
<secret value="TwlkZGxld2FyZUAyMDE3IQ=="/>
</server-identities>
...
1.7. In the same configuration file, in the <domain-controller> tag, update the remote
username to the new jbossadmin user:
...
<domain-controller>
<remote security-realm="ManagementRealm" username="jbossadmin">
...
1.8. Run the following commands on servera to start the host controller and connect to

358 JB348-RHJBEAP7-en-6-20170411
Instructions
1.9. Connect to serverb and edit the /opt/domain/configuration/host-slave.xml

file:

[student@serverb ~]$ cd /opt/domain/configuration
[student@serverb ~]$ sudo -u jboss vi host-slave.xml
1.10. Update the <secret value> tag to contain the new generated value:
...
<server-identities>
<secret value="TwlkZGxld2FyZUAyMDE3IQ=="/>
</server-identities>
...
1.11. In the same configuration file, in the <domain-controller> tag, update the remote
username to the new jbossadmin user:
...
<domain-controller>
<remote security-realm="ManagementRealm" username="jbossadmin">
...
1.12. Run the following commands on serverb to start the host controller and connect to

1.13. Run the following commands on workstation to start the load balancer:

1.14. Open Firefox on workstation and navigate to http://172.25.250.254:9990. Log

in with the new administrative credentials and verify that you can access the server.
2. The cluster.war application is already deployed. Navigate to the application at

http://172.25.250.254:9080/cluster. Refresh the page a few times to increase the
counter. Take note of which server is currently serving the request. Stop the server that is
currently serving the request and then refresh the page again.
JB348-RHJBEAP7-en-6-20170411 359
The clustering is not working because the counter does not persist between the two servers.
Examine the JGroups configuration to discover the reason for the clustering failure and then
fix the issue. Verify that the fix works by using the cluster.war application to ensure that
the counter persists between servers.
2.1. In a web browser, navigate to the cluster.war application at

http://172.25.250.254:9080/cluster.
2.2. Refresh the page a few times to increase the counter. Take note of which server is
currently serving the request. Return to the terminal and stop whichever server is
serving the request.
2.3. Return to the application and refresh the page again. The count resets. This indicates
that the cluster is not working properly.
Open a new terminal window and connect to the EAP CLI:
[student@workstation bin]$ sudo /opt/jboss-eap-7.0/bin/jboss-cli.sh \

-c --controller=172.25.250.254:9990
2.4. In the EAP CLI, run the following command to get information about the TCPPING stack
to see if it is correctly configured:
[domain@172.25.250.254:9990 /] /profile=full-ha/subsystem=\
jgroups/stack=tcpping:read-resource(recursive=true)
2.5. The initial_hosts value does not list all of the required servers and the ones it does
list have the incorrect ports. Update the initial hosts to contain all four servers on the
correct port. First, remove the TCPPING property with the following EAP CLI command:
jgroups/stack=tcpping/protocol=TCPPING/property="initial_hosts":remove
2.6. Add the servera and serverb hosts back to the initial hosts:
jgroups/stack=tcpping/protocol=TCPPING/property="initial_hosts":add\
(value="servera[7600],servera[7700],serverb[7600],serverb[7700]")
2.7. Restart the domain and host controllers.
2.8. Return to the cluster.war application at http://172.25.250.254:9080/

cluster. Refresh the page to increase the counter and then stop the server currently
serving the application. Refresh the page again and verify that the counter number
persists.
• Create a new persistent queue called LabQueue with the JNDI name java:/jboss/
360 JB348-RHJBEAP7-en-6-20170411
Instructions
• Create an expiry queue with the name LabQueueEXQ and the JNDI name java:/jboss/
exported/jms/queue/LabQueueEXQ that is not persistent.
• Create a DLQ with the name LabQueueDLQ and the JNDI name java:/jboss/
exported/jms/queue/LabQueueDLQ that is not persistent. The DLQ should be set as
the DLQ for the previously created LabQueue queue and should have a maximum delivery
attempts set to 3.
• Configure message persistence by setting the journal file size to 65536 and configure the
minimum number of files that make up the message journal to 5.
• For testing purposes, create a new credential with the following properties to send and
receive messages on both servera and serverb with the name lab-user and password
Lab@JMS59! in the group guest.
• The /home/student/JB348/apps/messaging-client.jar application is provided

to test the queue. Use the argument labsend to send messages and labdrain to drain
messages. Send 100 messages to the queue passing the following parameters:
◦ --user: lab-user
◦ --password: Lab@JMS59!
◦ --totalMessages: 100
• The messages are still not properly load-balanced. Configure the subsystem so that the
3.1. Go back to the terminal that is running the CLI and create the queue:

--queue-address=LabQueue \
--entries=java:/jboss/exported/jms/queue/LabQueue --durable=true
3.2. Configure the expiry queue to receive expired messages from the LabQueue with the
following properties:
• Persistence: no
Return to the terminal that is running CLI and create the queue with the specified
properties:

--queue-address=LabQueueEXQ \
--entries=java:/jboss/exported/jms/queue/LabQueueEXQ --durable=false
3.3. Configure new address settings to redirect expired messages:
JB348-RHJBEAP7-en-6-20170411 361
:add(expiry-address=jms.queue.LabQueueEXQ,expiry-delay=5000)
3.4. Configure the new DLQ queue to receive redelivered messages from the LabQueue
queue with the following properties:
• Persistence: No
3.5. Return to the terminal that is running the CLI and create the queue with the specified
properties:

--queue-address=LabQueueDLQ --durable=false \
--entries=java:/jboss/exported/jms/queue/LabQueueDLQ
:write-attribute(name=dead-letter-address, value=jms.queue.LabQueueDLQ)
3.7. Set the journal file size to 65536:
3.8. Because the LabQueue keeps on average 50 messages, the configuration needs a
minimum of 5 journal files. Set the minimum number of files that make up the message
journal to 5:
3.9. To enable the configuration, reload the hosts:
3.10.Create a new set of credentials with the following properties to send and receive
messages:
362 JB348-RHJBEAP7-en-6-20170411
Instructions
• User name: lab-user
• Password: Lab@JMS59!
• Group: guest
Open a terminal window on workstation and access servera using SSH:
Create the credentials:
[student@servera ~]$ cd /opt/jboss-eap-7.0/bin/

[student@servera bin]$ sudo -u jboss ./add-user.sh \
-p Lab@JMS59! -a
Exit from servera:
[student@servera bin]$ exit
3.11. Access serverb using SSH:
Create the credentials:
[student@serverb ~]$ cd /opt/jboss-eap-7.0/bin/

[student@serverb bin]$ sudo -u jboss ./add-user.sh \
-p Lab@JMS59! -a
Exit from serverb:
[student@serverb bin]$ exit
3.12. Send 100 messages to the queue, passing the following parameters to the /home/
student/JB348/apps/messaging-client.jar application:
Open a terminal window on workstation and send 100 messages:

labsend --user=lab-user --password=Lab@JMS59! --totalMessages=100
JB348-RHJBEAP7-en-6-20170411 363
Drain all messages from the queue:

labdrain --user=lab-user --password=Lab@JMS59!
3.13. At this point, because the message load balancing type is not set to strict, the servers
do not alternate the load automatically. Set this property to strict to force this behavior.
Return to the terminal that is running the CLI and configure the load balancer:
/server=default/cluster-connection=my-cluster\
Reload the hosts to enable the configuration:
3.14.Open a terminal window on workstation and send another 100 messages:

labsend --user=lab-user --password=Lab@JMS59! --totalMessages=100
Drain all messages from the queue:

labdrain --user=lab-user --password=Lab@JMS59!
Evaluation
364 JB348-RHJBEAP7-en-6-20170411
Lab: Comprehensive Review Part Two
Lab: Comprehensive Review Part Two
In this review, you will fix an existing CLI script used to provision both the production and
development environments. You will also create a cache and use the airports.war application
to the test the system.
Outcomes
• Debug and resolve issues with scripting.
• Deploy an Infinispan cache for use by an application.
Before you begin

Set up your VMs for this exercise by logging in to workstation as student, and running the
following command:
Instructions
You have inherited an EAP Managed Domain that contains a domain controller, two host
controllers, and two servers on each host controller.

The only VM with a graphical interface installed. It hosts EAP running a domain controller.
servera VM (IP: 172.25.254.10)

A text-based VM responsible for running two EAP instances managed by the domain
serverb VM (IP: 172.25.254.11)

• login: student
Complete the following tasks to fix the script:
• The administration console is available at http://172.25.250.254:9990 and the

credentials to access it are jbossadm/JBoss@RedHat123.
• Read the /home/student/JB348/labs/review2/script.cli script and identify the

problems.
JB348-RHJBEAP7-en-6-20170411 365
• Fix the problems in the /home/student/JB348/labs/review2/script.cli script.
• Deploy the application and the cache configuration needed by the application creating a script.
The application file is available at /home/student/JB348/labs/review2/airports.war.
• The cache container name for the devel server group must be airport.
• The cache must be a replication cache named airports.
• The JNDI name for the cache must be infinispan/airports_container/airports.
• All the updates must be synchronized.
• The transport setting must have a 60000 ms timeout.
• A file store must be configured with the following values:
path: airport-cache
This is the file that persists the cache.
relative to: airport.cache.destination

This is the path to the cache file.
passivation: false
False means that the cache store contains a copy of the contents in memory, so writes to
the cache result in cache store writes.
preload: true
True means that when the cache starts, data in the cache store is loaded into memory
during the boot process.
purge: false
False means that the cache store is not purged at boot process.
In a real-world project, backups from the controllers must be created. However, if something goes
wrong in this lab, you can stop the domain and host controllers and re-run the setup verb from
the grading script.
Evaluation
366 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
In this review, you will fix an existing CLI script used to provision both the production and
development environments. You will also create a cache and use the airports.war application
to the test the system.
Outcomes
• Debug and resolve issues with scripting.
• Deploy an Infinispan cache for use by an application.
Before you begin

Set up your VMs for this exercise by logging in to workstation as student, and running the
following command:
Instructions
You have inherited an EAP Managed Domain that contains a domain controller, two host
controllers, and two servers on each host controller.

The only VM with a graphical interface installed. It hosts EAP running a domain controller.
servera VM (IP: 172.25.254.10)

serverb VM (IP: 172.25.254.11)

• login: student
Complete the following tasks to fix the script:
• The administration console is available at http://172.25.250.254:9990 and the

credentials to access it are jbossadm/JBoss@RedHat123.
• Read the /home/student/JB348/labs/review2/script.cli script and identify the

problems.
JB348-RHJBEAP7-en-6-20170411 367
• Fix the problems in the /home/student/JB348/labs/review2/script.cli script.
• Deploy the application and the cache configuration needed by the application creating a script.
The application file is available at /home/student/JB348/labs/review2/airports.war.
• The cache container name for the devel server group must be airport.
• The cache must be a replication cache named airports.
• The JNDI name for the cache must be infinispan/airports_container/airports.
• All the updates must be synchronized.
• The transport setting must have a 60000 ms timeout.
• A file store must be configured with the following values:
path: airport-cache
relative to: airport.cache.destination

passivation: false
False means that the cache store contains a copy of the contents in memory, so writes to
the cache result in cache store writes.
preload: true
True means that when the cache starts, data in the cache store is loaded into memory
during the boot process.
purge: false
False means that the cache store is not purged at boot process.
In a real-world project, backups from the controllers must be created. However, if something goes
wrong in this lab, you can stop the domain and host controllers and re-run the setup verb from
the grading script.
Steps
1. Start the domain controller and the two host controllers.
1.1. On workstation, open a terminal window and start the domain controller by running
the following command:
[student@workstation ~]$ ./master.sh
Wait until the domain controller has started.
1.2. On workstation, open a new terminal window and start the host controller on
servera by running the following command:

[student@servera ~]$ ./host.sh
368 JB348-RHJBEAP7-en-6-20170411
Instructions
Wait until the host controller has started.
1.3. On workstation, open a new terminal window and start the host controller on
serverb by running the following command:

[student@serverb ~]$ ./host.sh
Wait until the host controller has started.
2. Run the script and identify the problem raised.
Leave the script downloaded to the same location and create a copy where all changes are
made.
[student@workstation ~]$ cp /home/student/JB348/labs/review2/script.cli \

/home/student
On workstation, run the following commands to test the script:
[student@workstation ~]$ /opt/boss-eap-7.0/bin/jboss-cli.sh \

--file=/home/student/script.cli
The following error is raised:
{
"outcome" => "failed",
"result" => {},
"failure-description" => {"host-failure-descriptions" =>
{"servera.lab.example.com" => "WFLYHC0078: Server (server-one) still running"}},
"rolled-back" => true
}
3. Fix the script.
3.1. Update the script.cli script to stop the servers by adding to the line after the
connect 172.25.250.254 command:
:stop-servers(blocking=true)
3.2. Add a new profile named production based on a full-ha profile.
Immediately after the server-group removals commands, add the following command:
/profile=full-ha:clone(to-profile=production)
3.3. Add a new profile named devel based on a full profile.
Immediately after the previous command line, add the following command:
/profile=ha:clone(to-profile=devel)
JB348-RHJBEAP7-en-6-20170411 369
3.4. Update the line where the server groups are created to associate the server groups with
an existing socket binding group.
#Create a server group using the production

/server-group=production:add(profile=production,socket-binding-group=full-ha-
sockets)
/server-group=devel:add(profile=devel,socket-binding-group=ha-sockets)
3.5. Change the script.cli script to create port offsets for the servers production-two
from the servera, and serverb hosts.
#Add production servers

/host=servera.lab.example.com/server-config=production-one:add(auto-start=true,
group=production)
/host=servera.lab.example.com/server-config=production-two:add(auto-start=true,
group=production,socket-binding-port-offset=100)
#Add development servers
/host=serverb.lab.example.com/server-config=devel-one:add(auto-start=true,
group=devel)
/host=serverb.lab.example.com/server-config=devel-two:add(auto-start=true,
group=devel,socket-binding-port-offset=100)
3.6. Test the changes.
Re-run the script from the existing terminal window:
[student@workstation ~]$ /opt/boss-eap-7.0/bin/jboss-cli.sh \

--file=/home/student/script.cli
4. Users are reporting that the Airport application has been returning results really
slowly. Create an Infinispan replicated cache with the JNDI name infinispan/
airports_container/airports and set the cache to be created during startup. Deploy
the airports.war application to the devel server-group. Use JConsole to monitor the
application. Restart the server and test the application and verify that subsequent searches
have improved speed.
4.1. Open a terminal window to start the CLI.
On workstation, run the following commands:
[student@workstation ~]$ /opt/jboss-eap-7.0/bin/jboss-cli.sh \

--connect --controller=172.25.250.254
4.2. Create a new path to persist the cache file.
[domain@172.25.250.254:9990 /] /path=airport.cache.destination\
:add(path=/opt/domain/cache)
4.3. Create a new cache container named airport. The cache container must have the
jndi-name defined as infinispan/airports_container:
370 JB348-RHJBEAP7-en-6-20170411
Instructions
[domain@172.25.250.254:9990 /] /profile=devel/subsystem=infinispan\
/cache-container=airport:add(jndi-name=infinispan/airports_container)
4.4. Set the timeout value, when obtaining locks for the transport, to one minute:
/cache-container=airport/transport=TRANSPORT:add(lock-timeout=60000)
4.5. Create a synchronized replicated cache named airports.
/cache-container=airport/replicated-cache=airports\
:add(jndi-name=infinispan/airports_container/airports, mode=SYNC)
4.6. Add a persistent file with the following properties to the cache container, to be used
when the server starts:
path: airport-cache
relative-to: airport.cache.destination
passivation: false
False means that the cache store contains a copy of the contents in memory, so
writes to cache result in cache store writes.
preload: true
True means that when the cache starts, data in the cache store is loaded into
memory during the boot process.
purge: false
False means that the cache store is not purged during startup.
[domain@172.25.250.254:9990 /] /profile=devel/subsystem=infinispan/\
cache-container=airport/replicated-cache=airports/\
file-store=FILE_STORE:add(path=airport-cache, \
relative-to=airport.cache.destination,\
passivation=false, preload=true, purge=false)
4.7. Reload the servers to enable the new configuration:
4.8. Deploy the /home/student/JB348/labs/review2/airports.war application to

the devel server group.
[domain@172.25.250.254:9990 /] deploy /home/student/JB348/apps/airports.war \

--server-groups=devel
JB348-RHJBEAP7-en-6-20170411 371
4.9. On workstation, open a web browser and navigate to

http://172.25.250.10:8080/airports. Enter kjfk in the ICAO code field.
The response time is much faster in subsequent calls because the cache was loaded
during the first request.
Evaluation
372 JB348-RHJBEAP7-en-6-20170411
Lab: Comprehensive Review Part Three
Lab: Comprehensive Review Part Three
In this review, a junior developer made some configuration changes to JBoss EAP 7.0 that caused
an application named database to stop working correctly, in addition to other changes. Using
the logging information generated by EAP, recover the application and the logging level to the
default ones used by EAP standalone full HA profile. Also update the network configuration from
EAP to allow access for any deployed application. The remaining network configuration must be
limited to 127.0.0.1. Finally, implement role-based access control (RBAC) to the management
console to restrict the junior developer's access to the management console.
Outcomes
• Debug issues using logging information.
• Solve the issues identified by the logging files.
• Enable RBAC to restrict access to the management console.
Before you begin

exercise:
Instructions
You have inherited an EAP standalone server running on the workstation VM.
The environment is based a single virtual machines running Red Hat Enterprise Linux 7 (RHEL 7)
with a minimal set of tools installed, including Java 8:
• workstation VM (IP: 172.25.250.254): The only VM with a graphical interface installed. It

will host the MySQL database and EAP running a standalone server.
• login: student
The server.sh script is provided to start EAP from the home directory. The jbossadm
username and the JBoss@RedHat123 password can be used to access the management
console.
• The http://127.0.0.1:8080/database URL enables database access to the application.

The embedded H2 database is used by this application.
• The logging subsystem must be configured to generate the output to the file.
JB348-RHJBEAP7-en-6-20170411 373
• The server network configuration must provide access to the applications using either
localhost or the workstation IP address. The remaining services must be accessible only
using 127.0.0.1.
• RBAC must be configured so that the junior user can only deploy applications.
Evaluation
374 JB348-RHJBEAP7-en-6-20170411
Solution
Solution
In this review, a junior developer made some configuration changes to JBoss EAP 7.0 that caused
an application named database to stop working correctly, in addition to other changes. Using
the logging information generated by EAP, recover the application and the logging level to the
default ones used by EAP standalone full HA profile. Also update the network configuration from
EAP to allow access for any deployed application. The remaining network configuration must be
limited to 127.0.0.1. Finally, implement role-based access control (RBAC) to the management
console to restrict the junior developer's access to the management console.
Outcomes
• Debug issues using logging information.
• Solve the issues identified by the logging files.
• Enable RBAC to restrict access to the management console.
Before you begin

exercise:
Instructions
You have inherited an EAP standalone server running on the workstation VM.
The environment is based a single virtual machines running Red Hat Enterprise Linux 7 (RHEL 7)
with a minimal set of tools installed, including Java 8:
• workstation VM (IP: 172.25.250.254): The only VM with a graphical interface installed. It

will host the MySQL database and EAP running a standalone server.
• login: student
The server.sh script is provided to start EAP from the home directory. The jbossadm
username and the JBoss@RedHat123 password can be used to access the management
console.
• The http://127.0.0.1:8080/database URL enables database access to the application.

The embedded H2 database is used by this application.
• The logging subsystem must be configured to generate the output to the file.
• The server network configuration must provide access to the applications using either
localhost or the workstation IP address. The remaining services must be accessible only
using 127.0.0.1.
JB348-RHJBEAP7-en-6-20170411 375
• RBAC must be configured so that the junior user can only deploy applications.
Steps
1. Start EAP using the server.sh script and evaluate the logs generated by EAP.
1.1. In a terminal window, run the following command to start EAP:
[student@workstation ~]$ ./server.sh
1.2. Evaluate the output from the logs.
By default, the logging level for the console output should not be displayed. Therefore,
the logging level needs to be changed.
Also, the database.war application is raising an error because there are some
dependencies missing. The log output indicates the data source is incorrectly
configured. It uses a MySQL as the back end database, but the application uses H2.
WFLYCTL0184: New missing/unsatisfied dependencies:

service jboss.jdbc-driver.mysql (missing) dependents: [service
org.wildfly.data-source.ExampleDS, service jboss.driver-demander.java:jboss/
datasources/ExampleDS]
2. Access EAP using the CLI to update the logging configuration to minimize the output from
the console window.
2.1. Open a new terminal window, and run the following command:
[student@workstation ~]$ /opt/jboss-eap-7.0/bin/jboss-cli.sh --connect
An EAP CLI opens and connects to the standalone server.
2.2. Update the ROOT logger to not log to the console. In the EAP CLI, run the following
command:
[standalone@localhost:9990 /] /subsystem=logging/root-logger=ROOT:\
write-attribute(name=handlers,value=[FILE])
2.3. Evaluate the changes.
In another terminal window, redeploy the database.war file.
[student@workstation ~]$ touch ~/standalone/deployments/database.war.failed
No output is expected from the console window running EAP.
3. Evaluate the data source with issues.
The existing data source is used by the database.war application, but it is using the wrong
configuration.
3.1. Evaluate the configuration from the data source.
376 JB348-RHJBEAP7-en-6-20170411
Instructions
In the CLI, execute the following command:
[standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:\
read-resource(recursive=true)
The data source is using a mysql driver, instead of the default h2 driver according to the
following output:
{
"result" => {
...
"driver-name" => "mysql",
...
}
3.2. Update the data source configuration to use the embedded h2 driver.
In the CLI, execute the following command:
[standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS\
:write-attribute(name=driver-name,value=h2)
3.3. Reload the server configuration file by running the reload command:
[standalone@localhost:9990 /] reload
3.4. Evaluate the output from the server using the log file.
From a new terminal window, run the following command:
[student@workstation ~]$ tail -f standalone/log/server.log
Even though the data source was fixed, the data source used by the database.war file
is still not working.
14:36:59,342 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1)

WFLYCTL0183: Service status report
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.clustering.web."database.war" (missing) dependents: [service
jboss.undertow.deployment.default-server.default-host./database.session]
service jboss.clustering.web.locator."database.war" (missing) dependents:
[service jboss.undertow.deployment.default-server.default-host./database.codec]
service jboss.clustering.web.locator."database.war".cache (missing)
dependents: [service jboss.clustering.web.locator."database.war"]
Keep this window open to check for further log output.
4. The database.war application connects to a data source whose JNDI name is

java:jboss/datasources/database according to the developer. To create it, run the
following command:
JB348-RHJBEAP7-en-6-20170411 377
[standalone@localhost:9990 /] data-source add --name=database \

--jndi-name=java:jboss/datasources/database --driver-name=h2 \
--connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE \
--user-name=sa --password=sa
After running the command, the following output is expected from the terminal window with
the log output.
2017-04-04 15:11:39,144 INFO [org.jboss.as.connector.subsystems.datasources]

(MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/
database]
2017-04-04 15:11:39,180 INFO [org.jboss.as.controller] (management-handler-thread -
6) WFLYCTL0183: Service status report
WFLYCTL0185: Newly corrected services:
service jboss.clustering.web."database.war" (no longer required)
5. Limit the administration web console access to localhost.
The management interface is accessible externally but it should only be visible on the local
machine. To make it visible to the local machine, execute the following commands from the
CLI:
[standalone@localhost:9990 /] /interface=management\
:write-attribute(name=inet-address,value=127.0.0.1)
6. Limit the access to the junior user.
6.1. Enable RBAC:
[standalone@localhost:9990 /] /core-service=management/\
access=authorization:write-attribute(name=provider,value=rbac)
6.2. Create a role named Administrator that can update the server configuration.
To create the role named Administrator, run the following command:
[standalone@localhost:9990 /] /core-service=management/access=authorization/\
role-mapping=Administrator:add(include-all=true)
6.3. Update the jbossadm user to be an administrator:
role-mapping=Administrator/include=user-jbossadm:add(name=jbossadm,type=USER,\
realm=ManagementRealm)
6.4. Create a junior user to become a Deployer.
In the CLI, run the following command to create the role:
378 JB348-RHJBEAP7-en-6-20170411
Instructions
role-mapping=Deployer:add
6.5. Create the junior user to become a Deployer.
In the CLI, run the following command to associate the user junior with the Deployer
role:
role-mapping=Deployer/include=user-junior:add(name=junior,type=USER,\
realm=ManagementRealm)
6.6. Create the junior user in the management realm.
Open a new terminal window and run the following commands:
[student@workstation ~]$ cd /opt/jboss-eap-7.0/bin/

[student@workstation bin]$ ./add-user.sh -sc \
/home/student/standalone/configuration
Use the following values:
• user type: Management
• user name: junior
• password: N00b13
• Accept the size of the password.
• Add no role to the user junior.
• Answer yes for all the following prompts.
6.7. Access the web console at http://workstation.lab.example.com:9990 as

the junior user and check that they can only deploy applications and cannot modify
configurations on the server.
Evaluation
JB348-RHJBEAP7-en-6-20170411 379
Summary
In this chapter, you practiced configuring clusters, creating CLI scripts, configuring caches, and
enabling audit logging.
380 JB348-RHJBEAP7-en-6-20170411

JB348 Red Hat JBoss Application Administration II

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JB348 Red Hat JBoss Application Administration II

Uploaded by

Copyright:

Available Formats

RED HAT®

Comprehensive, hands-on training that solves real world problems

Red Hat JBoss Application

© 2017 Red Hat, Inc. JB348-RHJBEAP7-en-6-20170411

Red Hat JBoss Enterprise Application Platform 7 JB348

Authors: Douglas Silva, Jim Rigsbee, Zachary Gutterman

Copyright © 2017 Red Hat, Inc.

No part of this publication may be stored in a retrieval system, transmitted or reproduced in

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a registered trademark of Silicon Graphics International Corp. or its subsidiaries in

All other trademarks are the property of their respective owners.

1. What's New in JBoss EAP 7? 1

2. Migrating to JBoss EAP 7 23

3. Configuring a JBoss EAP Cluster 49

4. Deploying Applications 107

5. Configuration and Management Scripting with CLI 139

Reviewing Configuration and Management Examples ................................................ 149

6. Monitoring and Management 175

7. Configuring and Tuning the Messaging System 215

8. Securing Applications 269

9. Securing EAP 307

• At least 2 years as a JBoss EAP Administrator.

• RHCJA EAP 7 certified administrator (recommended).

• Highly Recommended: Attend Red Hat JBoss Application Administration I (JB248)

Structure of the Course

Orientation to the Classroom Lab Environment

Controlling your station

The station timer

Per-user language selection

i=$(grep 'Language=' /var/lib/AccountService/users/${USER} \

[user@host ~]$ LANG=fr_FR.utf8 date

jeu. avril 24 17:55:01 CDT 2014

Input method settings

System-wide default language settings

[root@host ~]# localectl set-locale LANG=fr_FR.utf8

Language Codes Reference

WHAT'S NEW IN JBOSS EAP 7?

• Identify new features in the management console in JBoss

• Describe and explore the new features in JBoss EAP 7.

• Configuring EAP with the New Management Console (and

• Identify New Features in JBoss EAP 7 (and Quiz)

Identifying the New Specifications in Java EE 7

Technology JSR Description Subsystem

Technology JSR Description Subsystem

Quiz: What's New in JBoss EAP 7

Choose the correct answer to the following questions:

a. JSR 356 - WebSocket 1.1.

3. Which technology replaced JAX-RPC in JEE 7? (Choose one.)

a. JSR 356 - WebSocket 1.1.

3. Which technology replaced JAX-RPC in JEE 7? (Choose one.)

Configuring EAP with the New Management

Management console features

• A new home page for quick access for common tasks.

• Easier navigation, and enhanced support for large-scale domain configurations.

• Log visualization in the web console.

Redesigned home page

Log visualization in the management console

Guided Exercise: Configuring EAP with the

Before you begin

[student@workstation ~]$ lab explore-console setup

1. Start a Standalone Instance of EAP

[student@workstation ~]$ cd /opt/jboss-eap-7.0/bin

2. Navigate to the Management Console

• User Name: jbossadm