WildFly: New Features

By Filippe C Spolti
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
About this book
Publication date:
May 2014


Chapter 1. Starting with WildFly

The book will address the key subjects inherent to this technology that will provide the reader with some important information, which will help them understand Wildfly Application Server and its main functions. The target audience for this book will be the people who have an interest in knowing the technology, mainly administrators and developers. The WildFly server is the same as Jboss AS7, but with numerous improvements and features, improved modularity, and better performance. It is really impressive when compared to previous versions such as Jboss 5 and even other Application Servers such as Weblogic, and has strong support from the community at www.wildfly.org. I hope the audience accepts and adopts the use of Wildfly since it is a new technology and is in fact a very promising application server.


What is WildFly?

WildFly, better known as JBoss Application Server, is a Java EE application developed entirely in Java, and thus can be run on any operating system, both 32 -bit and 64-bit. Some readers may wonder why JBoss had its name changed after so many years. This is due to a lot of confusion that was generated between the names of the products in their portfolio, and not only the JBoss application server, explains Jason Andersen, Director of Red Hat products. The name WildFly was selected by a vote initiated in October 2012, which was formally presented to the public in JUDCon Brazil 2013. The name WildFly was among other top-rated potential names such as basejump, Petasos, Jocron, and JBeret. But what really matters is its performance and ease of use. More details on the vote held by the company is available at http://www.jboss.org/vote.

The new WildFly has a highly optimized boot process; its services are started at the same time in order to eliminate the waiting time between the start of one service to the start of another, and all services that are not required at the time of startup are kept on standby until the time of first use. The main characteristics that it emphasizes on are connectivity, responsiveness, and scalability, and the main factor behind the improvements on these fronts is a new web server called Undertow,which is more powerful than its competitors such as Jetty Web Server. Its memory management is very aggressive in order to minimize the maximum allocation of heap memory. All the services used by WildFly use common indexed metadata cached to avoid the duplication of metadata. They also have modular load that prevents the loading of duplicate classes and has to be loaded over the system required for booting. All these factors not only reduce the overhead of heap memory but dramatically reduce the pauses made by the garbage collector (GC, this pause may be eliminated using the JVM settings) and also allow WildFly to run on devices with limited physical resources. WildFly implements the latest Java EE 7 specification that improve developer productivity by providing an easier way to develop modern Java EE applications, without requiring a combination of various existing frameworks, allowing a development team to operate with focus on the business of a company.

Hierarchical classloading often causes several problems, mainly library conflicts between different versions of the same library, but this ended in WildFly thanks to its modular structure that only links the JAR file to your application when it needs it.

Unlike most previous versions of JBoss, WildFly has all your settings centralized in a single file that is divided into subsystems that can be changed according to your needs; this becomes very useful if we are using a domain with multiple servers. In such cases, we have a centralized configuration in a single file. All the settings are based not only on edition of files; all management features are exposed through a Command Line Interface (that will be discussed in greater detail throughout this book), a web management interface, a native Java API, and through the Rest API-based HTTP / JSON and JMX. WildFly offers two execution modes: standalone and domain. The main difference between them is on the basis of scalability; the standalone mode works alone and the domain mode works with one or more servers.

WildFly practically supports all current Java EE 7 standards of web development and also features support for standards including JAX-RS, Java API, and it is also highly tolerant of server failures that give us support for clustering, session replication, and other services. WildFly also has a very large reduction in management and service ports, but is now going to have only two, application and management ports. The following screenshot gives a list of protocols that are supported along with the ports they utilize:

Downloading WildFly

In addition to the final version, WildFly has several other alpha and beta versions mainly intended for testers whose primary purpose is to perform tests such as stress, load, response time, and so on. Furthermore, these versions allow the users to identify errors and bugs that are fixed in the next release.

Before starting the download, we must prepare the environment. For this book, the environment used will be as follows:

With the operating system installed, we will download and install Java later. I advise you to always perform a manual installation and configuration of the latest available version. The Java SDK can be downloaded from http://www.oracle.com/technetwork/pt/java/javase/downloads/index.html.

In this case, I will be choosing to download the RPM version because we are using a RedHat-like operating system, as in an OS, which is based on the Red Hat Linux operating system, where the RPM is the native package manager. After the download, we will install and configure Java.

Installing Java

After you download Java and have already copied the file to our test server, we can now begin the Java installation.

  1. Use the following command on the CentOS cmd:

    [root@wfly-book ~]# rpm -ivh jdk-7u45-linux-x64.rpm
    Preparing...            ########################################### [100%]
       1:jdk                ########################################### [100%]
    Unpacking JAR files...
  2. After installation, we must set the JAVA_HOME environment variable:

  3. Add the location of your Java installation under/etc/profile:

    #Java configuration
    export JAVA_HOME="/usr/java/jdk1.7.0_45"
    export PATH="$PATH:$JAVA_HOME/bin"
  4. Run the command below to apply the new configuration:

    [root@wfly_book ~]# source /etc/profile
  5. To check the integrity of the installation, just run a simple Java command to verify:

    [root@wfly_book ~]# java -version
    java version "1.7.0_45"
    Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
    Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

With the Java installation completed successfully, we are now able to go to the next topic.


The installation guide and basic configuration

At this point, we assume that Java is correctly installed and configured as discussed in the previous section.

Now we are ready to download WildFly and start our installation. The download of the WildFly application server is available at http://wildfly.org/downloads/.

After the download completes and the file is sent to the server, we can initiate the installation. For this example, we will use a compressed version in the TGZ format, such as wildfly-8.0.0.Final.tar.gz.

First we must define a directory to perform the installation; one of the ways that I use to standardize my installation is by always using the following directory structure:


Where {wfly_dir_name} is the name that you use to identify the instalation directory of your server.

Creating and accessing /opt/server using the following commands:

[root@wfly_book opt]# cd /opt/
[root@wfly_book opt]# mkdir /opt/server
[root@wfly_book opt]# cd /opt/server

Starting the WildFly extraction using the following commands:

[root@wfly_book server]# tar -xzvf /root/wildfly-8.0.0.Final.tar.gz
[root@wfly_book server]# ls

Note that the server directory has been created; we now have our WildFly application server installed. In the next topic, I'll talk a bit more about the installation and some basic settings, how to create a new user to access the management console and change the connection port numbers; we will also create a test application to perform a fresh deployment.

Before going on to the next step in which we will perform the first startup of the server, it is very interesting to understand how the subdirectories of WildFly are divided. The following are all the folders and their functions:

  • appclient: Configuration files, deployment content, and writable areas used by the application client container are run from this installation.

  • bin: All the server binaries, the startup script and also scripts that are used to setup the JVM startup parameters such as memory, heap memory size, among others, are present here.

  • docs: In this directory, the license files, sample configurations, documentation, and other documents are located that will increase your knowledge about WildFfy.

  • domain: This directory will only be used if the server is started in the domain mode. Inside are the settings files, deployments contents, and areas of writing used by the server to store log files and temporary files.

  • modules: The WildFly classloading is structured in a modular way. All the necessary modules are stored in this directory. Also, the new modules that are installed should be stored here following the directory pattern. This directory should only be modified if you know what you're doing to avoid classloading issues.

  • standalone: This directory will only be used when the server is started in the standalone mode. Here are configuration files, deployment contents, and areas of writing used by the server to store temporary files and logs, as well as the domain mode.

  • welcome-content: This is an area of internal use of the server that should not be used by end users unless they want to overwrite and insert their own application in the / context. Its alteration can influence the functioning of WildFly, welcome pages, or error messages that are present in this directory.

With a prior understanding of the function of each directory present in the WildFly installation, it is also very important to have an understanding of each of the modes in which WildFly works as well as knowing your directory structure; the possible modes of execution are the domain and standalone modes. A short description about them is given in the upcoming section.

Content of WildFly standalone and domain modes

The following directories are part of the Wildfly filesystem:

  • Configuration: It contains all the configuration files that are necessary to run this installation.

  • Deployments: This is the directory utilized to perforn your application deployments.

  • Lib/ext: This is the location for installed library jars referenced by applications using the Extension-List mechanism.

  • Tmp: These are the temporary files written by the server.

  • Data: This directory is not present on the domain mode. Here are files written by the server during startup and their lifecycle.

  • Log: These are the log files generated by the application server.

  • Content (only for domain): This directory must not be modified by end users. Here the Host Controller is stored in the internal work area for this installation.

  • Servers (only for domain): It is the writable area used by each application server instance that runs from this installation. Each application server instance will have its own subdirectory, created when the server is first started. In each server's subdirectory, there will be the following subdirectories:

    • data: This is the information written by the server that needs to survive a restart of the server

    • log: These are the server's log files

    • tmp: This is the location for temporary files written by the server

  • Tmp/auth (only for domain): This is the special location used to exchange authentication tokens with local clients, so they can confirm that they are local to the running AS process.

Overview of the configuration files

Basically, the main difference is in the management of the two modes.

The domain mode does not accept exploded deployment. Also, the domain mode allows centralized management of all running instances to perform the deploys across all group instances simultaneously, which may cause application downtime during the deploy. Meanwhile, the standalone mode keeps each single instance as a single server instance and it is not necessary to have a more complex configuration for implementation; the deployment can be performed instance by instance. The following is a brief explanation of each configuration present in the each WildFly 8 installation:

The standalone mode

The relevant files used in the standalone mode are explained as follows:

  • application-roles.properties: This is the file that contains the user permissions to access the applications. This file is changed by the user creation script that we will see later.

  • application-users.properties: This is the file that contains user information and password to access applications. This file is changed by the user creation script that we will see later.

  • mgmt-users.properties: This is the file that contains user information and password for access to the management console. This file is created by the user creation script available on the installation of the /bin directory.

  • mgmt-groups.properties: This file contains group information and administration permissions that the users have. This file is created by the user creation script.

  • logging.properties: This contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.

  • standalone-full-ha.xml: It is a Java Enterprise Edition 6 certified full-profile configuration file with a high availability and the full list of services.

  • standalone-ha.xml: It is a Java Enterprise Edition 6 certified full-profile configuration file with high availability and the basic services.

  • standalone-full.xml: It is a Java Enterprise Edition 6 full-profile certified configuration file that includes all the technologies required by the full-profile specification, including most other OSGI with the full services.

  • standalone.xml: It is a Java Enterprise Edition 6 full-profile certified configuration file that includes all the technologies required by the Full Profile specification including most other OSGI with the full services.

The domain mode

The relevant files used in the domain mode are explained as follows:

  • application-users.properties: This is the file that contains the user permissions to access the applications. This file is changed by the user creation script that we will see later.

  • application-roles.properties: This is the file that contains user information and password to access applications. This file is changed by the user creation script that we will see later.

  • default-server-logging.properties: These are additional logger configurations. The root logger will always be configured.

  • domain.xml: It is a Java Enterprise Edition 6 full-profile certified configuration file that includes the technologies required by the full profile specification plus others including OSGi.

  • host-master.xml: This contains all the information contained in the host.xml file; however, with a little difference, these configurations will be applied to the host master of the cluster. In the review of the file we have "A simple configuration for a host controller that only acts as the master domain controller and does not itself directly control any servers."

  • host-slave.xml: In this file, all the information that will be applied in the domain hosts slaves is present, that is., all instances of WildFly that make up the cluster.

  • host.xml: This is the host controller configuration file for the installation. Each cluster member must have its host.xml file that contains particular information for each site. It must have information such as the name of the instance of the cluster, configurations about how a new member will contact the domain to register and access the domain configuration settings, as well as specific physical installation, for example, the name of the network interface that will be used for executing the WildFly.

  • logging.properties: This contains the logging configuration for the host controller and process controller that run off this installation. It also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.

  • mgmt-users.properties: This is the file that contains user information and password for access to the management console. This file is created by the user creation script available on the installation of /bin.

  • mgmt-groups.properties: This file contains group information and administration permissions that the users have; this file is created by the user creation script.

Now that you know a bit about the structure of WildFly directories and subdirectories, as well as their possible modes of execution and its main configuration files, you may also want to deepen the content of the bin directory. It is the directory that contains all the operations contained in the server. The main ones start and stop WildFly and many other files access the bin directory to check this out.

The contents of the directory may seem a bit lengthy, but it is actually because the scripts are duplicated except those inside init.d. In this case, it is only usable in Linux RedHat or Debian and the service folder that is designed only for Windows. Both are binaries needed to run the WildFly as a service; all others are duplicated. All scripts with the sh extension are for Linux and all with the bat extension are for Windows. Now we will study only the main scripts based on scripts only for Linux, since Windows will have the same function. The following is a brief explanation of the principal scripts and that will be mostly used in everyday life:

  • add-user.sh: This is used to create an application or manage users that we will see later on in the chapter

  • domain.sh: This is the domain mode startup script

  • domain.conf: This is the boot configuration file that is used by domain.sh to set the boot parameters

  • standalone.sh: This is the standalone mode startup script

  • standalone.conf: This is the startup configuration file that is used by standalone.sh to set the boot parameters

The configuration files provide a little more detail. Instead of having the extension .conf, configuration files for Windows are terminated with .con f.bat.

Starting WildFly

WildFly has two execution modes, namely standalone and domain as previously described.

Starting the standalone mode

The following instructions will allow you to start WildFly in the standalone mode:

  1. Go to the bin directory of the installation. If you do not remember, you can get their location through the environment variable set previously, as shown in the following command:

    [root@wfly_book ~]# echo $JBOSS_HOME
  2. So just run the following command:

    [root@wfly_book ~]# cd $JBOSS_HOME/bin
  3. And then run WildFly in the standalone mode through the standalone.sh script as follows:

    [root@wfly_book bin]# ./standalone.sh

Note that during the boot we received a little warning saying it was unable to obtain the hostname using the previous method (InetAddress.getLocalHost ()). This method searches the hostname configured on the local DNS server; on Linux systems it is located under /etc /hosts. See the following warning:

16:35:20,783 WARN  [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012210: Unable to use InetAddress.getLocalHost() to resolve address.

To solve this problem just add the hostname of the machine under /etc/hosts. There are two ways to do this. We can use the loopback address ( or use the assigned address configured network interface (for example, eth0). For this example, we will use the network interface eth0.

To find your active interface type the following command:

  • Linux: ifconfig

  • Windows: ipconfig


These commands must be performed in a command-line tool (bash/cmd).

After the set up, the hosts file will look similar to the following lines of command:   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
#ip             #Hostname  wfly_book

Now when you run the ping command, the hostname should respond by the configured IP address:

[root@wfly_book bin]# ping wfly_book
PING wfly_book ( 56(84) bytes of data.
64 bytes from wfly_book ( icmp_seq=1 ttl=64 time=0.023 ms

You can see that the warning we saw in the last startup did not occur again. If the startup at this moment occurred as expected without any error, it means that the settings made so far are correct.

Starting the domain mode

Assuming that the local directory is now /bin, run the following command:

[root@wfly_book bin]# ./domain.sh

Note that, unlike the standalone mode that starts only one process, in this mode we have four processes started by default. They are explained as follows:

  • Host Controller: This process is the instance that acts as a central point of administration for all servers that are in the same domain

  • Process Controller: This process is responsible for rehabilitating and monitoring other processes during its life cycle

  • Server One: This is the process corresponding to the first server. It is the first instance of the WildFly domain

  • Server Two: This is the process corresponding to the second server. It is the second instance of the WildFly domain

It is also important that we change the bind IP address of an application server, so we can access it from another machine. By default, WildFly will listen only on the loopback interface, or localhost, as shown in the following command:

tcp        0      0    *                   LISTEN      2745/Java

This information was acquired through the netstat command. You can also get this information through the server logs as shown in the following command:

18:42:29,119 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017519: Undertow HTTP listener default listening on /

So we can change the bind address. We have two options to make this configuration. The first is by passing the parameter to the JVM and running the startup script from the command line or through the standalone.conf or domain.conf configuration files. The parameter responsible for this configuration is as follows:



Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

To change the bind address only for one time, it can be changed for any purpose whatsoever. Pass the parameter in the startup script as follows:

[root@wfly_book bin]# ./standalone.sh -Djboss.bind.address=<your ip address>

To permanently make this change so that every time the instance is started it remains active, we have two choices: using standalone|domain.conf or in the configuration file of the installation (stanalone|domain.xml).

In the standalone|domain.conf file, at the end of the next line add the configuration mentioned previously:

JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.bind.address=<your ip address>"

And we also have the option to change the XML configuration file for the actual installation. This method is not very advisable, because the configuration file works with variables. The jboss.bind.address parameter is nothing but a variable that can be amended by passing a parameter to the JVM; if nothing is passed, WildFly will assume the default value for this and any other variable present in the configuration file.

To do this, change the variable value passing its IP address, as follows:

<interface name="public">
     <inet-address value="${jboss.bind.address:<your ip address>}"/>

You can see that the bind address of WildFly now changes to what it was configured, using any of the ways mentioned earlier. Check the following part of the output:

19:13:05,888 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017519: Undertow HTTP listener default listening on /

And with the netstat command:

tcp        0      0*                 LISTEN      3070/java

We will access the running instance through a browser of your choice with the IP that was set up. In my case, the IP is and we have the following page displayed:


Other basic configurations

It is quite common in tests and production environments that we need to start more than one instance on the same server. WildFly has a very simple way to quickly set it. It is possible to start up an instance with all the doors changed very fast using a very convenient way. This configuration has a set of ports defined in the standalone xml / domain.xml configuration file; these define how many doors we want to add from the default ports. For example, if you want the next HTTP port to be 8081, just assign the value 1 instead of 0. If you want the port be 8090, simply assign the value 10, and so on. Here's how to make this setup simple. As an example, I will use the standalone.xml file.

Change the following line of code to turn the configuration permanent:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

Or just start the WildFly server passing these configurations as a parameter, as shown in the following command:

[root@wfly_book bin]# ./standalone.sh -Djboss.socket.binding.port-offset=10

The part that should be changed is highlighted; instead of 0, we can insert any desired value that will be added to the default port. We will see the default ports shown in the following lines of command:

<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>

Once you perform the following change, including setting the value 10 instead of 0. It is as if we did all the changes manually, and it would look similar to the following code:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:10}">
<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:10009}"/>
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:10000}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:10002}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8019}"/>
<socket-binding name="http" port="${jboss.http.port:8090}"/>
<socket-binding name="https" port="${jboss.https.port:8453}"/>
<socket-binding name="txn-recovery-environment" port="4802"/>
<socket-binding name="txn-status-manager" port="4803"/>

If we want to change only a port or more than a port through parameters during startup, it is very simple. We will change the default port to 9190 for the HTTP parameter passed when starting up the instance:

[root@wfly_book bin]# ./standalone.sh -Djboss.http.port=9190

The result is as shown in the following command:

JBAS017519: Undertow HTTP listener default listening on /

This can also be done using the netstat command:

[root@wfly_book ~]# netstat -anp | grep java
tcp        0      0*                   LISTEN      3713/Java

We now have the HTTP protocol listening on port 9190. You can change all the ports that WildFly uses, but each port has its own specific parameter and if you want to change them, you should assign the port for the parameter. The following is a list of all ports that can be changed using parameters:

  • -Djboss.management.native.port=<desired_port>

  • -Djboss.management.http.port=<desired_port>

  • -Djboss.management.https.port=<desired_port>

  • -Djboss.ajp.port=<desired_port>

  • -Djboss.http.port=<desired_port>

  • -Djboss.https.port=<desired_port>

Thus we can use the port we want in a very practical way.

In a new installation in Linux environments, it is quite common to use the root user. And often just leaving WildFly running with the root user is a security loophole, where WildFly has the root permissions on a server that is running and therefore can perform any operation that requires root permissions, such as shutting down the computer. An example of this was Versions 4 and 5 of JBoss where it is possible to perform a number of tasks that could compromise the functioning of the server, perform deployment of malicious applications, shutdown the server, obtain physical server information, and more. Since Version 7 of JBoss, it has became more complex, because now, management consoles in the new installation are protected in two ways., The first is with the address at which the interface is listening; by default, it is always the loopback address. The second protection is that, if a user needs to access a server that is not created, the web management console is inaccessible until the user is created and user passwords are protected by encryption. As a continuation of this chapter, we will learn how to run WildFly with a user, but without many privileges in our newly-configured environment.

The first step is to define a username and create it. In this case, to facilitate the identification of the user, I decided to create a user called wildfly because we can identify which applications this user owns.

The first step is to create the runtime user on the OS:

[root@wfly_book bin]# useradd wildfly -c "WildFly Server Runtime user"

The parameter-c is a comment that helps auditors and administrators to identify the user. If you do not want to change the password of the created user, it is not strictly necessary. However, if the password is not set for the user, he/she cannot log in unless you are already logged in as the rootuser. If you want to alter this, perform the following steps:

  1. The first step is to change the password for the user using the following commands:

    [root@wfly_book bin]# passwd wildfly
    Changing password for user wildfly.
    New password: Exampl3@test
    Retype new password:
    passwd: all authentication tokens updated successfully. 
  2. The next step is to grant read/write permissions in the WildFly server directory installation.

It is necessary that the created user can run WildFly so that the user becomes the owner of the installation directory and its subdirectories. He/she will need to perform read/write operations in these directories. If we do not do this, the server will throw an exception during startup. as shown in the following command:

[wildfly@wfly_book bin]$ ./standalone.sh

  JBoss Bootstrap Environment

  JBOSS_HOME: /opt/server/wildfly-8.0.0.CR1

  JAVA: /usr/java/jdk1.7.0_45/bin/java

  JAVA_OPTS:  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true


java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
Caused by: java.io.FileNotFoundException: /opt/server/wildfly-8.0.0.CR1/standalone/log/server.log (Permission denied)

You can see that we have a permission error in the log file. This is because it is the first file that WildFly tries to write during startup. To solve this problem, we need to change the owner of the files as shown in the following command:

[root@wfly_book ~]# chown -R wildfly.wildfly /opt/server/wildfly-8.0.0.CR1/

As you can see in the following commands, all the files currently belong to the root file:

[wildfly@wfly_book wildfly-8.0.0.CR1]$ ls -l
total 408
drwxr-xr-x. 3 root root   4096 Dec 22 04:12 appclient
drwxr-xr-x. 5 root root   4096 Jan  7 19:12 bin
-rw-r--r--. 1 root root   2451 Dec 22 04:12 copyright.txt
drwxr-xr-x. 4 root root   4096 Dec 22 04:12 docs
drwxr-xr-x. 7 root root   4096 Jan  7 17:24 domain
-rw-r--r--. 1 root root 351490 Dec 22 04:12 jboss-modules.jar
-rw-r--r--. 1 root root  26530 Dec 22 04:12 LICENSE.txt
drwxr-xr-x. 3 root root   4096 Dec 22 04:12 modules
-rw-r--r--. 1 root root   2356 Dec 22 04:12 README.txt
drwxr-xr-x. 8 root root   4096 Jan  7 16:35 standalone
drwxr-xr-x. 2 root root   4096 Jan  3 11:59 welcome-content

After running the previous command, note that the user wildfly is now the owner of all the files, as shown in the following commands:

[wildfly@wfly_book wildfly-8.0.0.CR1]$ ls -l
total 408

At this point, we can start the server with the user wildfly with no startup problems. Let's see what happens when we issue the following command:

JBAS015874: WildFly 8.0.0.CR1 "WildFly" started in 14358ms

The server starts successfully. Note that, when we see the process, the runtime user is wildfly, as shown in the following commands:

[root@wfly_book ~]# ps aux | grep java
wildfly   4033 13.4 56.0 1594376 136876 pts/0  Sl+  01:07   0:08 /usr/java/jdk1.7.0_45/bin/java -D[Standalone] -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.head
less=true -Dorg.jboss.boot.log.file=/opt/server/wildfly-8.0.0.CR1/standalone/log/server.log -Dlogging.configuration=file:/opt/server/wildfly-8.0.0.CR1/standalone/configuration/logging.properties -jar /opt/server/wildfly-8.0.0.CR1/jboss-modules.jar -mp /opt/server/wildfly-8.0.0.CR1/modules org.jboss.as.standalone -Djboss.home.dir=/opt/server/wildfly-8.0.0.CR1 -Djboss.server.base.dir=/opt/server/wildfly-8.0.0.CR1/standalone

Nowadays, we, mainly system administrators, have certain requirements to standardize our environments for easy understanding of how they are configured and consequently maintain a default on new installations.

One way to keep everything in order is to organize the applications by the services. The installation of WildFly comes with a pre-configured script for executing the server as a service. It is within the following directory:


To start, you must copy the configuration file wildfly.conf, present in the same directory, to /etc/default or simply make a symbolic link. In this case, I will make a symbolic link to the file wildlfy.conf as shown in the following commands:

 [root@wfly_book init.d]# ln -s /opt/server/wildfly-8.0.0.CR1/bin/init.d/wildfly.conf /etc/default/
[root@wfly_book init.d]# ls /etc/default/
nss  useradd  wildfly.conf

I am using CentOS, which is a RedHat-like operating system, and it will also make a symlink script wildfly-init.redhat.sh for /etc/init.d as shown in the following command:

[root@wfly_book init.d]# ln -s /opt/server/wildfly-8.0.0.CR1/bin/init.d/wildfly-init-redhat.sh /etc/init.d/wildfly

Before starting the service WildFly, we must change the wildfly.conf file uncommenting the most important configurations; these configurations are shown in the following code:


Let's try to start it now with the service command:

[root@wfly_book init.d]# service wildfly start
Starting wildfly:                                          [  OK  ]

And check the log using the following command:

JBAS015874: WildFly 8.0.0.CR1 "WildFly" started in 16362ms

And to stop the WildFly server, just run the following command:

[root@wfly_book init.d]# service wildfly stop
Stopping wildfly:                                          [  OK  ]


Since we already have our new application server configured, we will proceed to the next step; that is, to perform a deploy with a simple application and some more advanced settings about logs, datasources, installing new modules, and other useful features.

Knowing a lot about an application server is actually an important point and one that differentiates us from others when we impose some configuration that can improve performance and server security. This requires a deep knowledge of the directory structure and key files, settings, and functions. An administrator who does not know the application server will face many difficulties in solving a problem and finding the root cause. The resolution of problems in Java applications is complex. Why just know only one side of the coin? It is also necessary to know a bit of Java. Keeping a standard premises helps to maintain an organized environment; even if the environment has more than one administrator or a newly hired person, they will not have difficulty navigating the environment but will become familiar with it, because it follows a pattern.

About the Author
  • Filippe C Spolti

    Filippe Costa Spolti was born in Sao Joaquim, southern Brazil, considered one of the coldest cities in the country, but now lives in Minas Gerais. He works in the field of information technology and is a follower of the open source community. He contributes to open source projects, such as WildFly and Muffin. He currently works with management infrastructure in which the front-end is a park of physical and virtual servers running diverse critical business applications, and where he works mainly on the application servers, such as JBoss, Tomcat, and Apache. He is a professional, very flexible, and open to learning new technologies. He is a creator and maintainer of the hrStatus project, which is a free software for the DST Brazil. He is also currently working as an administrator of IBM PureSystems, which, by the way, was first deployed in Brazil and gave his company an international use case of the product.

    Browse publications by this author
Latest Reviews (1 reviews total)
WildFly: New Features
Unlock this book and the full library FREE for 7 days
Start now