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

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

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:

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

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

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 (127.0.0.1) 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:

After the set up, the hosts file will look similar to the following lines of command:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
#ip #Hostname
192.168.11.109 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 (192.168.11.109) 56(84) bytes of data.
64 bytes from wfly_book (192.168.11.109): 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.

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:

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 127.0.0.1:8080 0.0.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 /127.0.0.1:8080

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:

jboss.bind.address

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>}"/>
</interface>

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 /192.168.11.109:8080

And with the netstat command:

tcp 0 0 192.168.11.109:8080 0.0.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 192.168.11.109 and we have the following page displayed: