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.