Running WildFly in standalone mode

WildFly in the standalone mode means a WildFly instance is launched and managed on its own. You can have as many standalone WildFly instances as you like, but you will have to manage them separately. This means that every configuration, datasource, deployment, and module has to be managed once per instance.

Note

The main difference between the standalone and domain modes is about management and not about capabilities. Capabilities are determined by the profile you choose to run WildFly with.

Getting ready

Let's have a look into the standalone folder:

So, the configuration folder contains all the configuration files. Yes, you can have more than one, but you will have to choose which one to run with. The deployments folder contains all your applications to deploy, deployed and undeployed (as we will see later, there is even a marker for failed deployments). The folder lib contains all the library jars referenced by your applications using the Extension-List mechanism. Lastly, the log folder contains WildFly's server.log file.

As previously mentioned, in the configuration folder you will find the following files:

Along the lines of Java EE 7 profiles, WildFly defines its own profiles. For the standalone mode, each file corresponds to a WildFly profile, that is, standalone.xml corresponds to the default profile, standalone-ha.xml corresponds to the ha profile, standalone-full.xml corresponds to the full profile, and standalone-full-ha.xml corresponds to the full-ha profile. The same WildFly profiles will be found in the domain mode as well.

How to do it…

Let's try running WildFly in the standalone mode with its default settings, as follows:

$ cd $WILDFLY_HOME
$ ./bin/standalone.sh =========================================================================

 JBoss Bootstrap Environment

 JBOSS_HOME: /home/wildfly/WFC/wildfly

 JAVA: /home/wildfly/WFC/jdk8/bin/java

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

=========================================================================

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
08:43:50,658 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.2.Final
08:43:50,799 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final
08:43:50,850 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 9.0.0.Beta2 (WildFly Core 1.0.0.Beta2) starting
08:43:51,543 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 26) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
08:43:51,564 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
08:43:51,592 INFO [org.xnio] (MSC service thread 1-11) XNIO version 3.3.0.Final
08:43:51,601 INFO [org.xnio.nio] (MSC service thread 1-11) XNIO NIO Implementation Version 3.3.0.Final
08:43:51,627 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 54) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
08:43:51,626 INFO [org.jboss.as.security] (ServerService Thread Pool -- 53) WFLYSEC0002: Activating Security Subsystem
08:43:51,631 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 37) WFLYIO001: Worker 'default' has auto-configured to 16 core threads with 128 task threads based on your 8 available processors
08:43:51,635 INFO [org.jboss.as.security] (MSC service thread 1-10) WFLYSEC0001: Current PicketBox version=4.9.0.Beta2
08:43:51,649 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 44) WFLYJSF0007: Activated the following JSF Implementations: [main]
08:43:51,650 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 38) WFLYCLINF0001: Activating Infinispan subsystem.
08:43:51,680 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 46) WFLYNAM0001: Activating Naming Subsystem
08:43:51,686 INFO [org.jboss.remoting] (MSC service thread 1-11) JBoss Remoting version 4.0.8.Final
08:43:51,687 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 56) WFLYWS0002: Activating WebServices Extension
08:43:51,704 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
08:43:51,707 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0003: Undertow 1.2.0.Beta10 starting
08:43:51,707 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) WFLYUT0003: Undertow 1.2.0.Beta10 starting
08:43:51,714 INFO [org.jboss.as.connector] (MSC service thread 1-3) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.3.Final)
08:43:51,725 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = h2
08:43:51,813 INFO [org.jboss.as.naming] (MSC service thread 1-5) WFLYNAM0003: Starting Naming Service
08:43:51,814 INFO [org.jboss.as.mail.extension] (MSC service thread 1-7) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default]
08:43:51,876 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) WFLYUT0014: Creating file handler for path /Users/foogaro/wildfly9/wildfly-9.0.0.Beta2/welcome-content
08:43:51,904 INFO [org.wildfly.extension.undertow] (MSC service thread 1-16) WFLYUT0012: Started server default-server.
08:43:51,926 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting
08:43:51,990 INFO [org.wildfly.extension.undertow] (MSC service thread 1-12) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080
08:43:52,122 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-12) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
08:43:52,166 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /Users/foogaro/wildfly9/wildfly-9.0.0.Beta2/standalone/deployments
08:43:52,244 INFO [org.jboss.ws.common.management] (MSC service thread 1-11) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta3
08:43:52,403 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
08:43:52,403 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
08:43:52,403 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Beta2 (WildFly Core 1.0.0.Beta2) started in 1970ms - Started 202 of 379 services (210 services are lazy, passive or on-demand)

How it works…

The first few lines tell you where WildFly is located and the JVM options. What follows is the Undertow HTTP Listener, which is the component that processes the HTTP request, listening on http://127.0.0.1:8080. As a matter of fact, you can test that WildFly is running correctly by pointing to the previous address, and you should see something like the following image:

WildFly's welcome content

Next are the logs about WildFly's management listeners which I have emphasized. The first listener is the HTTP management listener, which is actually an HTTP API used to invoke commands over HTTP. The second one is the Admin Console, which provides you with a Web Console to simplify most of WildFly's configuration. The HTTP management interface and the Admin Console are listening respectively on http://127.0.0.1:9990/management and http://127.0.0.1:9990.

To access the Admin Console, open a browser and point it to http://127.0.0.1:9990/. What you should see is a page as depicted in the following image:

WildFly's management error page

WildFly is up and running, but the Admin Console is not visible at the moment because there is no user registered to the "security context" (the proper WildFly term is Realm) that the Admin Console belongs to. We will talk about security and realms later in this recipe and in the upcoming chapters.

Note

Hereby, whenever I use the term Admin Console or Web Console, they are to intend the same thing.

Furthermore, the preceding screenshot tells you how to create a user to access the Admin Console. We need to create the admin user by using the add-user.sh script provided by WildFly in its bin folder.

Once again, open your command line (you should never close it, unless you are shutting down your PC) and execute the following command:

$ cd $WILDFLY
$ ./bin/add-user.sh

The following screenshot is the result of the preceding code:

Examining the script and its interaction:

• In the preceding screenshot, the script first asks for a user type; in our case we need a management user. So just hit Enter or type a and then hit Enter. We do not need to create a user at the application level, used to create security context.
• We specify the username, for example wildfly.
• Then we need to enter the password following the specified policy. So we type cookbook.2015 and hit Enter.
• We confirm the password provided in the previous step by re-entering it.
• We confirm that we want to add our user "wildfly" to the ManagementRealm realm. So we type yes and hit Enter.
• In the final step, the script asks if the user will be used to connect one of the WildFly process to another one, or used to authenticate to an EJB. In this case, we type no and hit Enter.

Now, let's point to the admin address http://127.0.0.1:9990 again. The page now asks you to enter the username and the password. Specify wildfly as username and cookbook.2015 as password, and you should see the WildFly Admin Console as follows:

WildFly's Web Console

See also

We will take a deep pe into the standalone mode soon. In Chapter 2, Running WildFly in Standalone Mode, there will be described in detail all the configuration files, which one you should use, and how to manage your instance with both the Admin Console and the CLI. We will also deploy both the management tools.