In the previous article (https://qiita.com/tama1/items/829be5aacd81637ae73a), I wrote that there are three ways to deploy a web application to WildFly:
** 1. Deploy by placing it in the deployments folder (directory) ** ** 2. Deploy from the management screen ** ** 3. Deploy with management CLI **
This time, I will write about this area in a little more detail.
When you place an application (war file) in the deployments
directory, a ** deployment scanner ** that scans the deployments
directory at regular intervals deploys the application. There are two types of applications to be scanned: ** archive format ** and ** expanded format **.
** 1. Archive format ** It is a WEB application packed with zip. So-called war and ear files. ** 2. Deployment format ** It is a WEB application that expands zip. The extracted directory is named something like "xxx.war".
Deployment scanner settings can be found below in standalone.xml
.
<subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/>
</subsystem>
The deployment scanner setting items that can be set from the management screen are as follows.
item name | Description | Default value |
---|---|---|
Auto Deploy Exploded | Whether to redeploy when there is an update in the deployed WEB application | false |
Auto Deploy Xml | Whether to redeploy if the XML file is updated | true |
Auto Deploy Zipped | Whether to redeploy when there is an update in the archive format WEB application | true |
Deployment Timeout | An error will occur if the deployment times out or the deployment takes more than 600 seconds. | 600 |
Path | deployments directory name | deployments |
Relative To | System properties{jboss.server.base.dir}Path, by default "wildfly"-15.0.0.Final/Since it is "standalone", it is "wildfly" together with the "Path" setting.-15.0.0.Final/standalone/It will be "deployments". | jboss.server.base.dir |
Runtime Failure Causes Rollback | Is it necessary for a particular app to roll back all deployments when a runtime error occurs? | ${jboss.deployment.scanner.rollback.on.failure:false} |
Scan Enabled | Whether to enable scanning | true |
Scan Interval | Scan interval | 5000 |
In other words, in the default state, it is in the following state.
xxx.war.dodeploy
.Marker files can be created by the user to direct the deployment scanner, or by the deployment scanner to indicate the current status. Place it in the same directory as your application (war file), wildfly-15.0.0.Final / standalone / deployments
. If created by the user, the contents of the file can be empty.
** User-created marker file **
name | meaning |
---|---|
xxx.war.dodeploy | xxx.deploy war |
xxx.war.skipdeploy | xxx.Skip deploying war |
xxx.war.undeploy | xxx.Undeploy war * for some reasonmanualNot written in |
** Marker file created by the deployment scanner **
name | meaning |
---|---|
xxx.war.isdeploying | xxx.war is deploying |
xxx.war.deployed | xxx.The war deployment is complete |
xxx.war.failed | xxx.failed to deploy war |
xxx.war.isundeploying | xxx.war is undeploying |
xxx.war.undeployed | xxx.The undeployment of war is complete |
Deploy the application using WildFly's admin screen. The management screen is elaborate, and it seems that it is supposed to be used mainly (probably). What will happen if you deploy from the management screen
I think you can easily do it by following the instructions on the screen.
Select ʻUpload Deployment from the
(+) button at the top left of the
Deployments` menu.
Drag and drop the war file inside the dotted frame, or click the Choose a file or drag it here
link to select and upload the war file. After the upload is complete, press Next
to proceed.
Check the Name
and Runtime Name
, and set the ʻEnabled button to ʻON
if you want to enable it immediately. Runtime Name
is the context root. After confirming, press the Finish
button.
Deployment complete
Let's take a look at the deployments
directory, that? There is nothing.
When you open standalone.xml
, the following tags are added at the bottom.
<deployments>
<deployment name="helloworld.war" runtime-name="helloworld.war">
<content sha1="2be2e53cd283a40f626a947aa35bfbfb593893ec"/>
</deployment>
</deployments>
When I searched under the wildfly-15.0.0.Final
directory, I found such a file.
wildfly-15.0.0.Final/standalone/data/content/2b/e2e53cd283a40f626a947aa35bfbfb593893ec/content
I changed the extension to .zip and compared it with the war I uploaded earlier and it matched. It was uploaded in such a place.
Remove the application from the administration screen before proceeding.
The wildfly-15.0.0.Final / standalone / data / content / 2b / e2e53cd283a40f626a947aa35bfbfb593893ec / content
is gone and the tag added to standalone.xml
is gone.
wildfly-15.0.0.Final/bin/
の下にある管理CLIであるjboss-cli.sh
を使用してアプリケーションをデプロイします。Windowsの場合はjboss-cli.bat
を使います。
Connect to WildFly with jboss-cli.sh --connect
and run the deploy [write war location with full path]
command.
#wildfly-15.0.0.Final/bin/jboss-cli.sh --connect
[standalone@localhost:9990 /] deploy /yourpath/helloworld.war
The deployment is now complete.
When you open standalone.xml
, the following tags are added at the bottom.
<deployments>
<deployment name="helloworld.war" runtime-name="helloworld.war">
<content sha1="2be2e53cd283a40f626a947aa35bfbfb593893ec"/>
</deployment>
</deployments>
A content
file is also created.
wildfly-15.0.0.Final/standalone/data/content/2b/e2e53cd283a40f626a947aa35bfbfb593893ec/content
It seems to behave the same as when deploying from the management screen. Therefore, I think you should use whichever you like.
The documentation states that the product system should use the management API instead of the deployment scanner.
The idea seems to be that it is supposed to use deployment with a deployment scanner during development and use the management screen or management CLI after the production release.
8.2.2. Deploying Using the Deployment Scanner
Users are encouraged to use the WildFly management APIs to upload and deploy deployment content instead of relying on the deployment scanner that periodically scans the directory, particularly if running production systems.
Recommended Posts