(For more resources related to this topic, see here.)

The standalone/deployments directory, as in the previous releases of JBoss Application Server, is the location used by end users to perform their deployments and applications are automatically deployed into the server at runtime. The artifacts that can be used to deploy are as follows:

WAR (Web application Archive): This is a JAR file used to distribute a collection of JSP (Java Server Pages), servlets, Java classes, XML files, libraries, static web pages, and several other features that make up a web application.

EAR (Enterprise Archive): This type of file is used by Java EE for packaging one or more modules within a single file.

JAR (Java Archive): This is used to package multiple Java classes.

RAR (Resource Adapter Archive): This is an archive file that is defined in the JCA specification as the valid format for deployment of resource adapters on application servers. You can deploy a RAR file on the AS Java as a standalone component or as part of a larger application. In both cases, the adapter is available to all applications using a lookup procedure.

The deployment in WildFly has some deployment file markers that can be identified quickly, both by us and by WildFly, to understand what is the status of the artifact, whether it was deployed or not. The file markers always have the same name as the artifact that will deploy. A basic example is the marker used to indicate that my-first-app.war, a deployed application, will be the dodeploy suffix. Then in the directory to deploy, there will be a file created with the name my-first-app.war.dodeploy. Among these markers, there are others, explained as follows:

dodeploy: This suffix is inserted by the user, which indicates that the deployment scanner will deploy the artifact indicated. This marker is mostly important for exploded deployments.

skipdeploy: This marker disables the autodeploy mode while this file is present in the deploy directory, only for the artifact indicated.

isdeploying: This marker is placed by the deployment scanner service to indicate that it has noticed a .dodeploy file or a new or updated autodeploy mode and is in the process of deploying the content. This file will be erased by the deployment scanner so the deployment process finishes.

deployed: This marker is created by the deployment scanner to indicate that the content was deployed in the runtime.

failed: This marker is created by the deployment scanner to indicate that the deployment process failed.

isundeploying: This marker is created by the deployment scanner and indicates the file suffix .deployed was deleted and its contents will be undeployed. This marker will be deleted when the process is completely undeployed.

undeployed: This marker is created by the deployment scanner to indicate that the content was undeployed from the runtime.

pending: This marker is placed by the deployment scanner service to indicate that it has noticed the need to deploy content but has not yet instructed the server to deploy it.

When we deploy our first application, we'll see some of these marker files, making it easier to understand their functions. To support learning, the small applications that I made will be available on GitHub (https://github.com) and packaged using Maven (for further details about Maven, you can visit http://maven.apache.org/). To begin the deployment process, we perform a checkout of the first application.

First of all you need to install the Git client for Linux. To do this, use the following command:
```
[root@wfly_book ~]# yum install git –y
```

Git is also necessary to perform the Maven installation so that it is possible to perform the packaging process of our first application. Maven can be downloaded from http://maven.apache.org/download.cgi.

Once the download is complete, create a directory that will be used to perform the installation of Maven and unzip it into this directory. In my case, I chose the folder /opt as follows:
```
[root@wfly_book ~]# mkdir /opt/maven
```

Unzip the file into the newly created directory as follows:

[root@wfly_book maven]# tar -xzvf /root/apache-maven-3.2.1-bin.tar.gz
[root@wfly_book maven]# cd apache-maven-3.2.1/

Run the mvn command and, if any errors are returned, we must set the environment variable M3_HOME, described as follows:
```
[root@wfly_book ~]# mvn
-bash: mvn: command not found
```

If the error indicated previously occurs again, it is because the Maven binary was not found by the operating system; in this scenario, we must create and configure the environment variable that is responsible for this. First, two settings, populate the environment variable with the Maven installation directory and enter the directory in the PATH environment variable in the necessary binaries.

Access and edit the /etc/profile file, taking advantage of the configuration that we did earlier with the Java environment variable, and see how it will look with the Maven configuration file as well:
```
#Java and Maven configuration
export JAVA_HOME="/usr/java/jdk1.7.0_45"
export M3_HOME="/opt/maven/apache-maven-3.2.1"
export PATH="$PATH:$JAVA_HOME/bin:$M3_HOME/bin"
```

Save and close the file and then run the following command to apply the following settings:

Unlock access to the largest independent learning library in Tech for FREE!

Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.

Renews at €14.99/month. Cancel anytime
```
[root@wfly_book ~]# source /etc/profile
```

To verify the configuration performed, run the following command:
```
[root@wfly_book ~]# mvn -version
```

Well, now that we have the necessary tools to check out the application, let's begin. First, set a directory where the application's source codes will be saved as shown in the following command:
```
[root@wfly_book opt]# mkdir book_apps
[root@wfly_book opt]# cd book_apps/
```

Let's check out the project using the command, git clone; the repository is available at https://github.com/spolti/wfly_book.git. Perform the checkout using the following command:
```
[root@wfly_book book_apps]# git clone https://github.com/spolti/wfly_book.git
```

Access the newly created directory using the following command:
```
[root@wfly_book book_apps]# cd wfly_book/
```

For the first example, we will use the application called app1-v01, so access this directory and build and deploy the project by issuing the following commands. Make sure that the WildFly server is already running.

The first build is always very time-consuming, because Maven will download all the necessary libs to compile the project, project dependencies, and Maven libraries.

[root@wfly_book wfly_book]# cd app1-v01/
[root@wfly_book app1-v01]# mvn wildfly:deploy

For more details about the WildFly Maven plugin, please take a look at https://docs.jboss.org/wildfly/plugins/maven/latest/index.html.

The artifact will be generated and automatically deployed on WildFly Server.

Note that a message similar to the following is displayed stating that the application was successfully deployed:

INFO  [org.jboss.as.server] (ServerService Thread Pool -- 29) JBAS018559:
 Deployed "app1-v01.war" (runtime-name : "app1-v01.war")

When we perform the deployment of some artifact, and if we have not configured the virtual host or context root address, then in order to access the application we always need to use the application name without the suffix, because our application's address will be used for accessing it. The structure to access the application is http://<your-ip-address>:<port-number>/app1-v01/.

In my case, it would be http://192.168.11.109:8080/app1-v01/.

See the following screenshot of the application running. This application is very simple and is made using JSP and rescuing some system properties.

running-our-first-web-application-img-0

Note that in the deployments directory we have a marker file that indicates that the application was successfully deployed, as follows:

[root@wfly_book deployments]# ls -l total 20 -rw-r--r--. 1 wildfly wildfly 2544 Jan 21 07:33 app1-v01.war -rw-r--r--. 1 wildfly wildfly 12 Jan 21 07:33 app1-v01.war.deployed -rw-r--r--. 1 wildfly wildfly 8870 Dec 22 04:12 README.txt

To undeploy the application without having to remove the artifact, we need only remove the app1-v01.war.deployed file. This is done using the following command:

[root@wfly_book ~]# cd $JBOSS_HOME/standalone/deployments
[root@wfly_book deployments]# rm app1-v01.war.deployed
rm: remove regular file `app1-v01.war.deployed'? y

In the previous option, you will also need to press Y to remove the file. You can also use the WildFly Maven plugin for undeployment, using the following command:

[root@wfly_book deployments]# mvn wildfly:undeploy

Notice that the log is reporting that the application was undeployed and also note that a new marker, .undeployed, has been added indicating that the artifact is no longer active in the runtime server as follows:

INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018558:
 Undeployed "app1-v01.war" (runtime-name: "app1-v01.war")

And run the following command:

[root@wfly_book deployments]# ls -l total 20 -rw-r--r--. 1 wildfly wildfly 2544 Jan 21 07:33 app1-v01.war -rw-r--r--. 1 wildfly wildfly 12 Jan 21 09:44 app1-v01.war.undeployed -rw-r--r--. 1 wildfly wildfly 8870 Dec 22 04:12 README.txt [root@wfly_book deployments]#

If you make undeploy using the WildFly Maven plugin, the artifact will be deleted from the deployments directory.

Summary

In this article, we learn how to conﬁgure an application using a virtual host, the context root, and also how to use the logging tools that we now have available to use Java in some of our test applications, among several other very interesting settings.