WildFly Exploded Deployments with CLI: Difference between revisions
| (17 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
=Overview= | =Overview= | ||
Exploded deployments are not deployed by default by a WildFly instance. They can be triggered by [[WildFly_Exploded_Deployments_with_auto-deploy-exploded|configuring the deployment scanner]], using [[WildFly_Exploded_Deployments_with_Marker_Files|marker files]] or via CLI. The procedure to | Exploded deployments are not deployed by default by a WildFly instance. They can be triggered by [[WildFly_Exploded_Deployments_with_auto-deploy-exploded|configuring the deployment scanner]], using [[WildFly_Exploded_Deployments_with_Marker_Files|marker files]] or via CLI. The procedure to do an exploded deployment with CLI is described below. | ||
=Procedure= | =Procedure= | ||
| Line 11: | Line 11: | ||
=="Explode" the JEE archive== | =="Explode" the JEE archive== | ||
Expand the JEE archive | Expand the JEE archive. | ||
Expanding the archive in the | The archive can be expanded in any local directory accessible to the application server, not necessarily under the <tt>deployments</tt> directory. Expanding the archive in the <tt>deployments</tt> directory works but care must be taken not to interfere with the deployment scanner that monitors that directory. If you plan to manage the deployments this way and not rely on the deployment scanner, it is safe to comment out the deployment scanner subsystem configuration from the server configuration file. | ||
<blockquote style="background-color: Gold; border: solid thin Goldenrod;"> | |||
:<br>The name of the exploded root directory must end in the same extension as the JEE archive it is extracted from. If <tt>test.ear</tt> is deployed, then the exploded root directory name must end in <tt>.ear</tt>. The exploded root directory must contain the <tt>META-INF</tt> subdirectory, which holds the JEE deployment descriptors.<br><br> | |||
</blockquote> | |||
==Trigger the Deployment via CLI== | ==Trigger the Deployment via CLI== | ||
| Line 20: | Line 24: | ||
Trigger the deployment with the following command, providing appropriate values to the "runtime-name" and the "path" attributes. | Trigger the deployment with the following command, providing appropriate values to the "runtime-name" and the "path" attributes. | ||
"runtime-name" must end with the same JEE extension as the original JEE artifact. For example, if an EAR is deployed, the runtime name must end in ".ear". | |||
"path" must contain the absolute path of the exploded directory. As mentioned in the [[#.22Explode.22_the_JEE_archive|"Explode" the JEE archive]] section, the name must end with the appropriate JEE extension. | |||
<pre> | |||
[standalone@localhost:9999 /] /deployment=test:add(runtime-name="test.ear", enabled=true, content=[{"path"=>"/Users/ovidiu/tmp/exploded-test-dir.ear", "archive"=>false}]) | |||
</pre> | |||
==The Deployment Database== | |||
A successful deployment will update the standalone server configuration file with a section similar to: | |||
<pre> | <pre> | ||
... | |||
<deployments> | |||
<deployment name="test" runtime-name="test.ear"> | |||
<fs-exploded path="/Users/ovidiu/tmp/exploded-test-dir.ear"/> | |||
</deployment> | |||
</deployments> | |||
... | |||
</pre> | </pre> | ||
Note that the configuration will be maintained between restarts, the JEE application will be re-deployed after server restart. | |||
Latest revision as of 00:45, 1 April 2016
Internal
Overview
Exploded deployments are not deployed by default by a WildFly instance. They can be triggered by configuring the deployment scanner, using marker files or via CLI. The procedure to do an exploded deployment with CLI is described below.
Procedure
"Explode" the JEE archive
Expand the JEE archive.
The archive can be expanded in any local directory accessible to the application server, not necessarily under the deployments directory. Expanding the archive in the deployments directory works but care must be taken not to interfere with the deployment scanner that monitors that directory. If you plan to manage the deployments this way and not rely on the deployment scanner, it is safe to comment out the deployment scanner subsystem configuration from the server configuration file.
The name of the exploded root directory must end in the same extension as the JEE archive it is extracted from. If test.ear is deployed, then the exploded root directory name must end in .ear. The exploded root directory must contain the META-INF subdirectory, which holds the JEE deployment descriptors.
Trigger the Deployment via CLI
Connect the CLI to the application server instance. For more details on how to connect CLI see Connect to a Controller.
Trigger the deployment with the following command, providing appropriate values to the "runtime-name" and the "path" attributes.
"runtime-name" must end with the same JEE extension as the original JEE artifact. For example, if an EAR is deployed, the runtime name must end in ".ear".
"path" must contain the absolute path of the exploded directory. As mentioned in the "Explode" the JEE archive section, the name must end with the appropriate JEE extension.
[standalone@localhost:9999 /] /deployment=test:add(runtime-name="test.ear", enabled=true, content=[{"path"=>"/Users/ovidiu/tmp/exploded-test-dir.ear", "archive"=>false}])
The Deployment Database
A successful deployment will update the standalone server configuration file with a section similar to:
...
<deployments>
<deployment name="test" runtime-name="test.ear">
<fs-exploded path="/Users/ovidiu/tmp/exploded-test-dir.ear"/>
</deployment>
</deployments>
...
Note that the configuration will be maintained between restarts, the JEE application will be re-deployed after server restart.