This tutorial discusses how to deploy applications on WildFly application server. We can deploy applications on the top of WildFly in several ways:
1. File system copy (standalone mode only)
2. Using the Management Interfaces (Admin Console or CLI)
3. Using Maven to deploy WildFly applications
Deploying applications on WildFly using File system deployment
File system is the old school approach to deploy applications that is well known to the majority of developers. This kind of deployment is available on standalone mode only. Therefore, if you are about to deploy applications on a WildFly domain, you have to use the standard management instruments (CLI or Admin Console).
File system deployment just requires that you copy an archive zip into the deployments folder, in order to deploy your application. Example:
$ cp example.war /opt/wildfly-14.0.0.Final/standalone/deployments
You should then expect to find in your server’s log some evidence of your deployment along with the dependencies activated by your deployment. In our case,since we deployed a web application, we will find the following info on the server’s Console:
12:35:13,724 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS018210: Register web context: /example 12:35:13,872 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "example.war" (runtime-name : "example.war")
What just happened is that a process named the Deployment scanner picked up your application and prepared it for deployment. The scanner can operate in one of following modes:
Deployment mode 1: Auto-deploy mode
When running in auto-deploy mode, the scanner will directly monitor the deployment content, automatically deploying new content and redeploying content whose timestamp has changed. This is similar to the behavior of previous JBoss AS releases, except that the deployment scanner will not monitor any more changes in deployment descriptors, since Java EE 6/7 applications do not require deployment descriptors.
Deployment mode 2: Manual mode
When running the manual deploy mode, the scanner will not attempt to deploy the application. Instead, the scanner relies on a system of marker files, with the user’s addition or removal of a marker file serving as a sort of command telling the scanner to deploy, undeploy or redeploy content.
TIP: The default rule is that archived applications use the auto-deploy mode while exploded archives require manual deploy mode.
In order to perform manual deploy mode, you have to add a marker file named application.dodeploy to the deployment folder.
For example supposing you want to deploy the Example.ear folder to the deployments folder, using a Linux machine:
$ cp -r Example.ear $JBOSS_HOME/standalone/deployments $ touch $JBOSS_HOME/standalone/deployments/Example.ear.dodeploy
IMPORTANT: In case a deployment fails, the deployment scanner places a marker file application.failed (ex.Example.ear.failed) in the deployment directory to indicate that the given content failed to deploy into the runtime. The content of the file will include some information about the cause of the failure. Note that with uto-deploy mode, removing this file will make the deployment eligible for deployment again.
Configuring the Deployment scanner attributes
The deployment scanner attributes are part of the deployment-scanner subsystem. Out of the box there is a deployment scanner named “default” which contains the deployment settings that we have described at the beginning of this chapter.
/subsystem=deployment-scanner/scanner=default:read-resource
{
"outcome" => "success",
"result" => {
"auto-deploy-exploded" => false,
"auto-deploy-xml" => true,
"auto-deploy-zipped" => true,
"deployment-timeout" => 600,
"path" => "deployments",
"relative-to" => "jboss.server.base.dir",
"runtime-failure-causes-rollback" => expression "${jboss.deployment.scan
ner.rollback.on.failure:false}",
"scan-enabled" => true,
"scan-interval" => 5000
}
}
Here is a short description of the scanner attributes:
- enabled: set to true (default) to enable the Deployment scanner.
- path: the deployment scanner will scan this folder. If “Path Relative To” is configured, this will be the Path relative to that variable, otherwise it is intended to be an absolute path.
- relative to: This is the file system path will be appended to the Path variable (default jboss.server.base.dir). It’s an optional attribute.
- scan-interval: this is the amount of time between each directory scan.
- auto-deploy-exploded:when set to true, automatically deploys exploded archives. (default false).
- auto-deploy-zipped:when set to true automatically deploys zipped archives (default true).
- auto-deploy-xml: when set to true, resources contained in XML files (e.g. datasources, resource adapters) are automatically deployed.
- deployment-timeout: sets the time limit to complete an application deployment (default 600 seconds).
- runtime-failure-causes-rollback: This flag indicates whether a runtime failure of a deployment causes a rollback of the deployment as well as all other (even unrelated) deployments as part of the scan operation.
By setting the attributes of the default deployment scanner, you can customize its behavior. For example, if you want to allow automatic deployment of exploded archives then you can issue from the CLI the following command:
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-exploded,value=true)
How to find the version of an application
WildFly does not keep track of your application versions. You can however browse into the application’s artifacts and inspect the version available from Maven. For example, if you were to deploy the helloworld.war application from WildFly quickstarts, you can use the attachment command to display the version available from the pom.xml file:
[standalone@localhost:9990 /] attachment display --operation=/deployment=helloworld.war:read-content(path=META-INF/maven/org.wildfly.quickstarts/helloworld/pom.xml) | grep version
Continue your journey through WildFly Deployment:
1) Deploying applications on WildFly using the Web Console and the CLI
2) Configuring Maven WildFly plugin
Found the article helpful? if so please follow us on Socials
