The Java language has undergone many changes since its first release and will continue to adapt to meet the needs of the developer. Oracle, which acquired Sun in 2010, stated that its high-level Java strategy is to enhance and extend the reach of Java to new and emerging software development objectives; simplify, optimize, and integrate the Java platform into new deployment architectures; and invest in the Java developer community allowing for increased participation.
This has certainly been true in the Enterprise edition of Java, the main focus of which has been improved developer productivity, providing support for HTML5, and meeting enterprise demands. Out of all the Enterprise Java releases, Java EE 7 has been the most transparent and open to community participation. By allowing public feedback, the demands of the community can be realized and used to help shape Java EE 7 for the better, ultimately adding to the growth and success of Enterprise Java.
In addition, a large number of open source projects are used within the application server, such as Hibernate and Undertow. Integrating all these libraries does not come without a price because each library has evolved with complexity and requires more and more additional libraries to work.
As most IT experts agree, the challenge for today's application servers is to combine a rich set of features requested by customers along with a lightweight and flexible container configuration.
WildFly 8 is the direct continuation to the JBoss AS project. The renaming of the community version of JBoss AS was done to reduce confusion between the open source JBoss server, the JBoss community, and the JBoss Enterprise Application Platform (JBoss EAP). WildFly 8 is free and open source, with support coming from the JBoss community, whereas JBoss EAP is a licensed product that comes with support from RedHat.
The most notable updates in WildFly 8 from earlier versions are as follows:
Java EE7 certification: WildFly is a fully compliant Java EE enterprise server, which means that it provides reference implementations for all Java Specification Requests (JSRs) that make up Java EE 7. JSRs are basically change requests for the Java language. For more information on how JSRs work, refer to https://www.jcp.org/en/jsr/overview.
Arrival of Undertow: JBoss Web has been completely removed and replaced with Undertow. Undertow is a cutting-edge web server that supports non-blocking and blocking handlers, web sockets, and asynchronous servlets. It has been designed for scalability and maximum throughput. It is easy to use, easy to configure, and is highly customizable.
Port Reduction: The number of open ports has been greatly reduced in WildFly. Only two ports are open: 8080 and 9990. This has been achieved by multiplexing protocols over HTTP using the HTTP upgrade feature of Undertow.
Clustering: Clustering in WildFly is heavily refactored and includes many new features, including web sessions, single sign-on, and mod_cluster support for Undertow. There is also a new public clustering API and new @Stateful EJB caching implementation.
In this chapter, we will cover the following topics:
Installing the Java environment
Installing WildFly 8
Installing JBoss tools
Exploring the application server filesystem
Understanding the WildFly kernel
As far as hardware requirements are concerned, you should be aware that the server distribution, at the time of writing, requires about 150 MB of hard disk space and allocates a minimum of 64 MB and a maximum of 512 MB for a standalone server.
In order to get started, we are going to perform the following steps:
Download and install the Java Development Kit.
Download and install WildFly 8.
Download and install the Eclipse development environment. While we will use Eclipse in this book, you are free to use your IDE of choice.
At the end of this chapter, you will have all the required software installed and will be ready to start working with the application server.
WildFly is written in Java; therefore it needs a Java Virtual Machine (JVM) in which to run, along with the standard edition Java libraries. So, before we can get started setting up or learning about WildFly, we first need to install the Java Development Kit (JDK).
To use WildFly, you will need at least Java SE 7 or above. Although there is no plan to use Java 8 language changes within the WildFly 8.x source code, WildFly is compiled against Java 8. It is recommended that you use the latest version of Java SE 8 to run WildFly.
So, let's move to the Oracle download page, http://www.oracle.com/technetwork/java/javase/downloads/index.html, which now hosts all JDK downloads, as shown in the following screenshot:
This will take you to the download page for the latest JDK. At the time of writing, this was Java 8 update 5. You will need to accept the license agreement before downloading the JDK. Choose to download the latest version of Java for your operating system. Have a look at the following screenshot:
The download will take a few minutes depending how fast your network is.
tar -xzvf jdk-8u5-linux-x64.tar.gz
Next, you need to add the path as an environment variable. This can be achieved by adding the following lines to your user profile script (the
.profile file found in your home directory):
export JAVA_HOME=/installDir/jdk1.8.0_05 export PATH=$JAVA_HOME/bin:$PATH
Windows users can simply run the executable (
.exe) file to start the installation. The name of the installer varies depending on the operating system and your system architecture (32-bit or 64-bit); however, the steps will be the same—just the name will change. At the time of writing, the installer for the latest version of Java for 64-bit Windows is called
When using Windows, you should stay away from installation paths that include empty spaces, such as
C:\Program Files, as this leads to some issues when referencing the core libraries. An installation path such as
C:\Software\Java or simply
C:\Java is a better alternative.
When the installation is complete, you will need to update a couple of settings on the computer so that it will know where to find Java. The most important setting is
JAVA_HOME, which is directly referenced by the WildFly startup script.
If you are running Windows XP/2000, follow these steps:
Right-click on My Computer, and select Properties from the context menu.
On the Advanced tab, click on the Environment Variables button.
Then, in the System variables box, click on New.
Name the new variable
JAVA_HOME, and give a value of the path to your JDK installation; I recommend something like
Windows 7 tip
Because of increased security in Windows 7, standard users must have User Account Control (UAC) turned on to change the environment variables, and the change must be completed via user accounts. In the User Accounts window, under Tasks, select Change my environment variables. Use the New, Edit, or Delete button to amend environment variables
Now it's time to modify the system's
PATHvariable. Double-click on the
PATHsystem variable. In the box that pops up, navigate to the end of the Variable Value line, add a semicolon to the end, and then add the path to your JDK. This will be something like
The WildFly application server can be downloaded for free from the WildFly site, http://www.wildfly.org/downloads/. Have a look at the following screenshot:
You will notice that there is an option to download a minimalistic core distribution. This is aimed at developers who want to build their own application runtime using the WildFly 8 architecture.
Choose to download the full Java EE7 distribution. Like JBoss AS 7, WildFly does not come with an installer. It is simply a matter of extracting the compressed archive to a location of your choosing.
Linux users can extract the file using the
unzip command (depending on the type of compressed file you downloaded):
tar -xzvf wildfly-8.1.0.Final.tar.gz unzip wildfly-8.1.0.Final.zip
For those of you using Windows, you can use WinZip or WinRAR, taking care to choose a folder that does not contain empty spaces.
Unix/Linux users should be aware that WildFly does not require root privileges, as none of the default ports used by WildFly are below the privileged port range of 1024. To reduce the risk of users gaining root privileges through WildFly, install and run WildFly as a non-root user.
After installing WildFly, it is wise to perform a simple startup test to validate that there are no problems with your Java configuration. To test your installation, move to the
bin directory of your WildFly install and issue the following command:
For Linux/Unix users:
For Windows users:
The following screenshot shows a sample WildFly 8 startup console:
The preceding command starts up a WildFly standalone instance that's equivalent to starting the application server with the
run.sh script used by releases prior to JBoss AS 7. The
run.sh file remains in the WildFly
bin directory but is merely a placeholder and will not start the application server.
Notice how fast the application server starts. This is due to the modular architecture of WildFly. Essential services are started concurrently on boot-up, and non-critical services are started only when needed, resulting in an exceptionally fast startup. Local caching means that the server will start even quicker second time round!
If you need to customize the startup properties of your application server, then you need to open and modify the
standalone.conf file (or
standalone.conf.bat for Windows users). This file contains the memory requirements of WildFly. The following is the Linux core section of it:
if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true" JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true" fi
Java SE 8 users
PermGen has been replaced with Metaspace in Java 8. If you are using Java 8, then remove the
-XX:MaxPermSize=256m property from the
standalone.conf file, and replace it with
-XX:MaxMetaspaceSize=256m. This will prevent VM warnings being printed to your WildFly logs on startup.
By default, the application server starts with a minimum heap space memory requirement of 64 MB and a maximum requirement of 512 MB. This will be just enough to get started; however, if you need to run a core Java EE application on it, you will likely require a minimum of 1 GB of heap space. More realistically, you will need 2 GB or more depending on your application type. Generally speaking, 32-bit machines cannot execute a process whose space exceeds 4 GB; however, on 64-bit machines, there's essentially no limit to process the size.
You can verify that the server is reachable from the network by simply pointing your browser to the application server's welcome page, which is reachable by default at the well-known address:
http://localhost:8080. Have a look at the following screenshot:
If you have been using releases of the application server prior to JBoss AS 7, you might have heard about the
twiddle command-line utility that queries the MBeans installed on the application server. This utility was replaced in JBoss AS 7 and is still used in WildFly. Its replacement is a more sophisticated interface named the command-line interface (CLI), which can be found in the
References to JBOSS_HOME
Although the community version of JBoss AS has been renamed to WildFly, you will see that the properties in the startup scripts continue to use the property,
JBOSS_HOME, to reference the install directory of WildFly. For this reason, we will continue to use
JBOSS_HOME when referring to the root install of WildFly.
Just launch the
jboss-cli.sh script (or
jboss-cli.bat for Windows users), and you will be able to manage the application server via a shell interface, as shown in the following screenshot. Bear in mind that the server needs to be running in order to connect via the CLI.
Once you are in the shell session, if you are unsure of what commands can be issued, you can simply press the Tab button to display all possible commands. If your command is partly typed, and there is only one possible matching command, your command will be autocompleted. Those of you who use Linux will be used to this type of command-line assistance.
In the preceding screenshot, we have just connected to the server using the
connect command, which, by default, uses the loopback server address and plugs into port number 9990.
The CLI is discussed in depth in Chapter 7, Using the Management Interfaces, which is all about the server-management interfaces. We will have an initial taste of its basic functionalities in the following sections, to get you accustomed to this powerful tool.
Probably the easiest way to stop WildFly is to send an interrupt signal using Ctrl + C. This should be done in the same console window in which you issued the startup command, that is, where the server is running.
However, if your WildFly process was launched in the background or is running on another machine (see in the following sections), then you can use the CLI interface to issue an immediate
shutdown command as follows:
[disconnected /] connect [standalone@localhost:9990 /] shutdown [disconnected /]
There is actually one more option to shut down the application server, which is pretty useful if you need to shut down the server from within a script. This option consists of passing the
--connect option to the admin shell, thereby switching off the interactive mode as follows:
jboss-cli.sh --connect command=:shutdown # Unix / Linux jboss-cli.bat --connect command=:shutdown # Windows
[disconnected /] connect 192.168.1.10 [192.168.1.10:9990 /] shutdown
Remotely accessing WildFly via the CLI requires authentication. Check out Chapter 10, Securing WildFly, for more information about it. It also requires that the management interface on the remote WildFly install is opened to allow remote connections. This is covered in detail in Chapter 7, Using the Management Interfaces.
[disconnected /] connect [standalone@localhost:9990 /] reload
Although the main focus of this book is the administration of the WildFly application server, we are also concerned with application packaging and deployment. For this reason, we will sometimes add examples that require a development environment to be installed on your machine.
The development environment used in this book is Eclipse. Eclipse is known by developers worldwide and contains a huge set of plugins, building on its core functionality. If you are comfortable with another IDE, then feel free to use it, but this book will demonstrate Eclipse only. At the time of writing this, only Eclipse and NetBeans have plugins for WildFly.
So let's move to the Eclipse download page, located at http://www.eclipse.org/downloads.
From this page, download the latest Enterprise edition. The compressed package contains all the Java EE plugins already installed and requires about 248 MB of disk space. Have a look at the following screenshot:
If you are using Java 8, you should make sure you download Eclipse Luna (4.4) or the patched Version of 4.3.
Once you have downloaded Eclipse, unzip it to a folder of your choice. The extracted folder will be called
eclipse. To start Eclipse, navigate to the
eclipse folder and run:
Windows users can simply double-click on the executable file contained in the
eclipse folder (the one with the big, blue, round eclipse icon).
From the menu, navigate to Help | Eclipse Marketplace.
Then, search for the plugin you want to install (in this case, type
Finally, click on Install as shown in the following screenshot:
Make sure you select the version of JBoss tools that matches your version of Eclipse, for example, Luna or Kepler. In this case, we are using Eclipse Luna, so I have selected the Luna version of JBoss tools. If you want to install just the WildFly adapter, select JBossAS Tools. Agree to the terms and click on OK. Restart Eclipse when prompted to do so.
You can now set up the WildFly server in Eclipse by performing the following steps:
Now that we are done with the installation of all the necessary tools, we will concentrate on the application server structure. The first thing you'll notice when you browse through the application server folders is that its filesystem is basically divided into two core parts: the dichotomy reflects the distinction between standalone servers and domain servers.
The concept of a domain server is not new in the market of application servers, however, it was only introduced in JBoss with AS 7 as a way to manage and coordinate a set of instances of the application server. An application server node which is not configured as part of a domain is qualified as a standalone server. A standalone server resembles, in practice, a single instance of the application server you used to see in releases of the application server prior to JBoss AS 7.
We will discuss the concept of domains in detail in Chapter 5, Configuring a WildFly Domain. For the time being, we will explore the different filesystem structures for both kinds of servers.
From a bird's-eye perspective, we can see that the main filesystem is split in two: one section that is pertinent to domain servers and another that is relative to standalone servers. The following diagram depicts the tree of the application server:
bin folder is where you will find all your startup scripts, such as
domain.sh. In addition to the startup scripts, you can find
standalone.conf, which can be used to customize WildFly's bootstrap process.
As you saw earlier, the
bin folder also includes the
jboss-cli.sh script (
jboss-cli.bin for Windows users), which starts the interactive CLI. You will also find various other useful scripts, such as
vault.sh. This folder also contains the web services utility scripts (
wsprovide.sh) used to generate the web services definition language and the corresponding Java interfaces.
examples folder contains numerous configuration examples, from a minimalistic standalone example to an ec2 HA example (HA meaning high availability, and ec2 referring to Amazon Elastic Compute Cloud).
The main configuration file is
domain.xml, which contains all services that are used by the nodes of the domain. It also configures the socket-binding interfaces for all services.
The last file contained in the configuration folder is
logging.properties, which is used to define the logging format of the bootstrap process for both the process controller (PC) and host controller.
libfolder hosts the subfolder
ext, which is there to support Java SE/EE style extensions. Some of the application server deployers are able to scan this folder for additional libraries that are picked up by the local class loader. Nevertheless, this approach is not recommended and is maintained only for compliance with the language specifications. The
modulesfolder should be used to install your libraries within WildFly.
serversfolder holds a set of subfolders for each server defined in the configuration file. The most useful directory contained beneath each server is the
logfolder, which is the location where single instances emit their log.
If you are running the application server in standalone mode, this is the part of the filesystem you will be interested in. Its structure is quite similar to the
domain folder with the notable exception of a
deployment folder. Let's proceed with order. Just below the
standalone folder, you will find the following set of subdirectories:
The content and use of these subdirectories is explained as follows:
configurationfolder contains the application server configuration files. As a matter of fact, the application server ships with a set of different configuration files, each one using a different set of extensions. Launching the standalone startup script without passing in any parameters will, by default, use the
standalone.xml, this folder contains the
logging.propertiesfile that configures the logging of the bootstrap process. The other files you will find here are
mgmt-group.properties, which can be used to secure the management interfaces. Security is discussed in detail in Chapter 10, Securing WildFly.
deploymentsfolder is the location in which users can place their deployment content (for example, WAR, EAR, JAR, and SAR files) to have it automatically deployed in the server runtime. Users, particularly those running production systems, are encouraged to use WildFly's management APIs to upload and deploy deployment content instead of relying on the deployment scanner subsystem that periodically scans this directory. See Chapter 6, Application Structure and Deployment, for more details.
logfolder contains the logs emitted by the standalone instance of the application server. The default logfile, named
server.log, is, by default, truncated every time the server is rebooted. This can be configured within the
welcome-content folder contains the default page, which is loaded when you browse to the root of your application server (
http://localhost:8080). In terms of web server configuration, this is the Web root context.
Historically, JBoss AS releases used to manage their set of libraries in different ways. Let's recap to bring about some order. Earlier, Release 4.x was used to define the core server libraries into the
JBOSS_HOME/server libraries. Thereafter, each server definition had its specific library in the
This approach was pretty simple, however, it led to a useless proliferation of libraries that were replicated in the
default/all server distribution.
Releases 5.x and 6.x had the concept of the
common/lib folder, which was the main repository for all modules that were common to all server definitions. Each server distribution still contained a
server/<servername>/lib path for the libraries that were specific to that server definition. Unchanged from the earlier release was the repository for core server modules comprised by
JBoss AS 7 followed a more modular approach improving over all the earlier approaches. This modular approach remains unchanged in WildFly. The server bootstrap library,
jboss-modules.jar, can be found in the root of the application server. This single archive is all you need to bootstrap WildFly's application server kernel.
The main system modules are located in the
system/layers/base folder under the
modules folder. This has changed slightly in WildFly as, in JBoss AS 7, all modules were defined directly in the
The following table outlines the diverse approaches used across different server releases:
5.x and 6.x
7.x and 8.x
Listing all the modules will take up too much space, however, the module repository layout is often the same as the module name. For example, the
org.jboss.as.ejb3 module can be found in the
org/jboss/as/ejb3 subfolder of the
modules folder. This approach to organizing the modules certainly makes sense, and if you are used to a maven repository layout structure, you will have no problem getting your head around it.
In the last section of this chapter, we will see how modules are actually loaded by the application server.
WildFly's kernel was redesigned in JBoss AS 7. Understanding the details of the modular kernel will help you understand concepts introduced later in the book. The kernel is based on two main projects, as follows:
Modular Service Container (MSC): This project provides a way to install, uninstall, and manage services used by a container. MSC further enables resource injection into services and dependency management between services.
Learning more about JBoss modules is essential if you want to understand the server configuration discussed in the next few chapters. At its heart, a module is really just a wrapper for a JAR file but treated by the application container as a module. The reason for this is class loading and dependency management, as each module can be treated as a pluggable unit, as depicted by the next diagram. WildFly has two different types of modules; the only difference between them is the way they are packaged:
Have a look at the following screenshot:
Using a static module is the simplest way to load a module, and it's used as the default module when starting up the application server. Static modules are defined within the
JBOSS_HOME/modules/system/layers/base directory. Each module has a configuration file called
module.xml. The following example shows the contents of the
<module xmlns="urn:jboss:module:1.3" name="javax.batch.api"> <resources> <resource-root path="jboss-batch-api_1.0_spec-1.0.0.Final.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.enterprise.api"/> </dependencies> </module>
As you can see, a module definition contains two main elements, the resources defined in the module (and their path) and the module's dependencies. In this example, the main resource is
jboss-batch-api_1.0_spec-1.0.0.Final.jar, contained in the same folder as the
module.xml file. It has dependencies on two other modules,
A module which is defined with a
main-class element is said to be executable. In other words, the module name can be listed on the command line, and the standard static
main(String) method in the named module's
main-class will be loaded and executed.
Creating custom static modules is useful should you have many applications deployed to your server, which rely on the same third-party libraries. This means that you do not have to deploy multiple applications with the same bundled libraries. The other benefit to creating custom static modules is that you can declare explicit dependencies on other static modules. Installing modules is covered in Chapter 3, Configuring Enterprise Services, in which we install a JDBC driver as a module.
Firstly, we can add the module information, such as its dependencies, within the
MANIFESTfile within your JAR, for example, in the Main class
The second way to do this is by adding the dependency to the
jboss-deployment-structure.xmlfile, as shown in the following code:
<jboss-deployment-structure> <deployment> <dependencies> <module name="org.jboss.logging" /> </dependencies> </deployment> </jboss-deployment-structure>
We will cover this in more detail in Chapter 6, Application Structure and Deployment, in which we explain class loading.
In this chapter, we outlined the latest features that come shipped with WildFly.
We have seen that WildFly is composed of modular architecture, and that the kernel of WildFly is made up of two separate projects: JBoss Modules and MSC.
This modular architecture results in an exceptionally light kernel that is able to load modules as required, resulting in a quicker startup time.
The physical structure of the application server reflects the dichotomy between standalone servers and domain servers, the former being a single node instance and the latter a set of managed resources controlled by a domain controller and a host controller.
In the next chapter, we will dig deeper into the details of how to configure the application server, focusing our attention on the standalone server configuration file (
standalone.xml), which contains the configuration for both the core application server and the stack of enterprise services running on top of it.