mule -app foo
Application Deployment
Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version. |
Start a Mule Runtime
Start Mule by running <MULE_HOME>/bin/mule
or starting Mule as a service. By default, all applications in the <MULE_HOME>/apps
directory deploy.
Application Hot Deployment
Mule applications, either zipped or exploded can be dropped into $MULE_HOME/apps. If the Mule runtime is already started, the application deploys dynamically.
All applications in Mule are unpacked at runtime and the original zip is removed. This means, for example, that dropping a zip file into the 'apps' dir creates a new folder with the same name (without the 'zip' extension) and delete the zip. |
A successful app deployment is confirmed by:
-
Having an unpacked application folder in the apps dir. For example, for
stockTrader.zip
-$MULE_HOME/apps/stockTrader
. -
An anchor file created for a running app, for example,
$MULE_HOME/apps/stockTrader-anchor.txt
If you wish to store your applications in a different location, you can do this on Unix-based systems by creating a symlink to your application directory from $MULE_HOME/apps
.
Start a Mule Runtime and Deploy Specific Applications
You can also include the -app flag when you start a Mule runtime. This flag designates the applications to start (separated by the colon - :).
For example:
Where foo
is a Mule application at $MULE_HOME/apps/foo
.
In this case the Mule runtime respects the specified order when starting the applications, and only the applications specified are started.
mule -app first:second
Where first
and second
are both Mule application folders in $MULE_HOME/apps/
.
Undeploying Applications
Don’t delete the application folder directly, but rather delete an app’s anchor file only:
Deleting only the app’s anchor file:
-
Prevents any interference from the hot-deployment layer and doesn’t leave room for concurrent conflicting actions.
-
Avoids potential application jar locking issues on some operation systems and allows for clean shutdown and undeployment.
For example, if the stockTrader
app is running (app folder is there as well as the $MULE_HOME/apps/stockTrader-anchor.txt
file, just delete the anchor file to have the app removed from the Mule instance at runtime. Application folder is removed after the app terminates.
Note: After undeploying a Mule Application, there is a timeout of 15 seconds until LoggerContext stops. Log files for an application only release after this timeout expires. This information is important in Windows, where you can’t remove files that are in use by other processes.
Application Hot Redeployment
After a Mule application is deployed into a Mule runtime, the Mule runtime polls the $MULE_HOME/apps
folder every three seconds for updates to $MULE_HOME/apps/<appname>/mule-config.xml
(or any config.resources file specified in an application’s mule-deploy.properties file). You can update or replace the application folder contents and touch/modify the application’s configuration file to have Mule reload the config and automatically re-deploy the application.
Hot Deploying Application Updates at Runtime
Updating a Mule application at runtime can be a complex change involving class modifications, endpoint modifications, changing ports, and reconfigured flows. As a result, application update cause a graceful app shutdown under the hood and reconfigures itself. In practice, this is transparent to the user and happens within seconds.
There are several ways an application can be updated:
-
By dropping the modifications over an existing exploded app folder and touching the 'master' configuration file (
mule-config.xml
in app root by default). -
By dropping a new zipped version of the app into
$MULE_HOME/apps
dir (with the same name). Mule detects this as an existing app update and ensures a clean redeployment of the app. Note that any modifications to the old app folder are discarded - the new app folder is a clean exploded application from a zip.
As you see, both integrate with existing build tools, the preference for one over another really depends on established development practices only.
Hot redeployment can be dangerous in a production environment. It may be safer to undeploy the production application first, then replace the Mule application deployable archive. For some application changes, such as modified files in the application’s classpath, you may also need to restart the Mule runtime before deploying the new application version. |
Sharing Resources
If you’re deploying multiple applications to the same place and those applications share the same resources, you can create a common domain where you define common configurations that can be referenced by multiple projects. This allows you to, for example, expose different services in different projects through the same HTTP host and port and be able to deploy everything without any conflicts. See Shared Resources.
Disabling the Mule Container Mode
If you want to run Mule 3 the legacy 2.x way, edit $MULE_HOME/conf/wrapper.conf
file and replace the following lines:
# Java Main class
wrapper.java.mainclass=org.mule.module.reboot.MuleContainerBootstrap
With:
# Java Main class
wrapper.java.mainclass=org.mule.module.boot.MuleBootstrap
When run in this legacy mode, none of the new application deployment features apply.