Deploying an application via the CLI

In this recipe, we will learn how to deploy an application using the CLI. Here we will use just the basic options but keep in mind that you have several options during deployments, which we will analyze deeply in the chapter dedicated to the CLI.

Getting ready

In this recipe, and in the following one as well, we will need an application to test our configuration. For this recipe, we will need the application named example that you can find in my GitHub repository. If you skipped the Managing applications using the deployments folder recipe, please refer to it to download the source code and the projects that you will need.

How to do it…

1. With your WildFly instance up and running, open up a terminal and connect to the CLI as usual:

   $ ./bin/jboss-cli.sh --connect
   [standalone@localhost:9990 /]

2. Now we need to tell the CLI to deploy our application as follows:

   [standalone@localhost:9990 /] deploy example.war
   [standalone@localhost:9990 /]

3. And let's have a look at the server.log files:

   23:02:29,511 INFO  [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /home/luigi/WFC/wildfly/standalone/data/content/21/7dd6250d5bc4afcabdffb0b25c99db92239b5a/content
   23:02:29,517 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "example.war" (runtime-name: "example.war")
   23:02:29,613 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0021: Registered web context: /example
   23:02:29,641 INFO  [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0010: Deployed "example.war" (runtime-name : "example.war")

4. Now, let's check it for deployment from the CLI:

   [standalone@localhost:9990 /] deployment-info --name=example.war
   NAME        RUNTIME-NAME PERSISTENT ENABLED STATUS
   example.war example.war  true       true    OK     
   [standalone@localhost:9990 /]

How it works…

I emphasized a log line to take your attention. As you can see, WildFly automatically saves its artifacts into its data/content folder. In that folder, you will find a lot of folders with hashed names that contain the artifact. The artifact is then renamed as content.

If you try to see the content file information using the unzip command, you will find your artifact structure as seen in the following screenshot:

There's more…

You can also deploy an artifact disabled, with status stopped, and enable it at your convenience as follows:

[standalone@localhost:9990 /] deploy example.war --disabled

This will just add the artifact into the data/content folder of WildFly in your running-mode, to enable it later:

[standalone@localhost:9990 /] deploy --name=example.war

There is also a reference to the deployment inside the standalone.xml configuration file; open it and scroll down to the end.

Standalone.xml updated after a deploy

Yes, you will find the name and the runtime-name along with the hash. In the How it works... section, I showed you where the deployment really persists, and in that case, it was stored into the $WILDFLY_HOME/standalone/data/content/ folder.

Did you notice it? The first two characters of the sha1 value denote the first folder, the rest of the sha1 hash is the subfolder that contains the artifact renamed as content.

Tip

Getting the original deployment file can sometimes save your life, especially when dealing with a production environment, where last minute works are not "integrated" that much. Be safe with your backup.

Let's have a look at the deployments folder now. It's empty. That is because everything goes into the runtime data/content folder. Try to stop the instance and copy the example.war application into the deployments folder.

Now start the instance again. What do you get? Something similar to the following:

23:16:54,708 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.2.Final
23:16:54,934 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final
23:16:55,003 INFO  [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 9.0.0.Beta2 (WildFly Core 1.0.0.Beta2) starting
23:16:56,170 INFO  [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 20) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
23:16:56,243 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"example.war\")]"
23:16:56,249 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
23:16:56,260 INFO  [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
23:16:56,285 INFO  [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Full 9.0.0.Beta2 (WildFly Core 1.0.0.Beta2) stopped in 16ms

This is because you tried to deploy the same artifact twice, once using the CLI and once using the deployment folder. There is a listener called deployment-scanner that is triggered whenever you modify the content of the deployment folder. By the way, you can solve the preceding problem using the CLI, or by removing the auto-generated XML code into standalone.xml and leaving the artifact in the deployments folder.