Book Image

WildFly Configuration, Deployment, and Administration

By : Francesco Marchioni, Christopher Adam M Ritchie
Book Image

WildFly Configuration, Deployment, and Administration

By: Francesco Marchioni, Christopher Adam M Ritchie

Overview of this book

Table of Contents (19 chapters)
WildFly Configuration, Deployment, and Administration Second Edition
About the Author
About the Reviewers

Exploring the application server filesystem

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:

In the next section, we will dig deeper into the folder structure of the WildFly application server, dissecting its content and looking at what it is used for.

The bin folder

The bin folder is where you will find all your startup scripts, such as and 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 script (jboss-cli.bin for Windows users), which starts the interactive CLI. You will also find various other useful scripts, such as and This folder also contains the web services utility scripts ( and used to generate the web services definition language and the corresponding Java interfaces.

There are several subfolders within the bin directory. The service folder and the init.d folder contain programs that allow you to install WildFly as service on Windows and Linux, respectively.

The docs folder

The docs folder contains two subfolders, examples and schema. The schema folder contains all the .xsd schema definition files used by the configuration as schema.

The 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 domain folder

The next folder is the domain folder, which contains the domain structure split across a set of folders:

  • The configuration folder contains all the configuration files:

    • 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.

    • Another key file for domains is host.xml, which is used to define the host controller (HC).

    • The last file contained in the configuration folder is, which is used to define the logging format of the bootstrap process for both the process controller (PC) and host controller.

  • The content folder is used as a repository to store deployed modules.

  • The lib folder 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 modules folder should be used to install your libraries within WildFly.

  • The log folder, as you might imagine, contains the logging output of the domain. The file, by default, is truncated every time the server is rebooted.

  • The servers folder holds a set of subfolders for each server defined in the configuration file. The most useful directory contained beneath each server is the log folder, which is the location where single instances emit their log.

  • The data folder is used by the application server to store its runtime data, such as transaction logging.

  • Finally, the tmp folder is used to store temporary files written by the server.

The standalone folder

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:

  • configuration

  • data

  • deployments

  • lib

  • log

  • tmp

The content and use of these subdirectories is explained as follows:

  • The configuration folder 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 configuration file.

    Besides standalone.xml, this folder contains the file that configures the logging of the bootstrap process. The other files you will find here are and, which can be used to secure the management interfaces. Security is discussed in detail in Chapter 10, Securing WildFly.

  • The data folder is used by the application server to store its runtime data, such as transaction logging.

  • The deployments folder 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.

  • The lib folder hosts the subfolder ext, which is used to define extensions of the application server. The same considerations for the domain's lib path apply here.

  • The log folder 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 standalone.xml file.

  • The tmp folder is used to save temporary files written by WildFly.

The welcome-content folder

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.

The modules folder

Beneath the modules folder, you will find the application server's set of libraries, which are a part of the server distribution.

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 server/<servername>/lib folder.

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_HOME/server.

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 modules folder.

The following table outlines the diverse approaches used across different server releases:

AS release

Bootstrap libraries

Server libraries




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 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.

Understanding WildFly's kernel

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:

  • JBoss Modules: This project handles class loading of resources in the container. You can think about JBoss modules as a thin bootstrap wrapper for executing an application in a modular environment.

  • 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.

The following diagram depicts the basic architecture of WildFly's server kernel:

With this information, we can now progress to the loading of server modules.

Loading application server modules

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:

  • Static modules

  • Dynamic modules

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 javax.batch.api module.xml file:

<module xmlns="urn:jboss:module:1.3" name="javax.batch.api">
        <resource-root path="jboss-batch-api_1.0_spec-1.0.0.Final.jar"/>
        <module name="javax.api"/>
        <module name="javax.enterprise.api"/>

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, javax.api and javax.enterprise.api.

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.

The other way to approach the module repository is by using dynamic modules. This can be achieved in two ways, as follows:

  • Firstly, we can add the module information, such as its dependencies, within the MANIFEST file within your JAR, for example, in the Main class mypackage/MyClass:

    Dependencies: org.jboss.logging
  • The second way to do this is by adding the dependency to the jboss-deployment-structure.xml file, as shown in the following code:

          <module name="org.jboss.logging" />

We will cover this in more detail in Chapter 6, Application Structure and Deployment, in which we explain class loading.