Application Deployment

Start mule by running <MULE_HOME>/bin/mule or starting Mule as a service. By default, applications in the <MULE_HOME>/apps directory are deployed. You can also designate specific applications to start (separated by a colon - :) and Mule 3 respects the order when starting the applications. In this scenario, only the applications specified are started.

Start Mule by specifying an app to run:

Where foo is a Mule app at $MULE_HOME/apps/foo.

From this moment, Mule checks every three seconds for the $MULE_HOME/apps/foo/mule-config.xml updates. One can update the application jar contents and touch/modify this file to have Mule reload the config and class modifications.

Note: When using the -app option, hot deployment doesn’t work. Only the applications that are in the apps directory when the hot deployment script is run are deployed, new applications aren’t started until Mule restarts.

Mule applications, either zipped or exploded can be dropped into $MULE_HOME/apps. If Mule is already running, the application is deployed dynamically.

Note: All applications in Mule are unpacked at runtime and the original zip is removed. This means, for example, that dropping a zip file into 'apps' dir creates a new folder with the same name (without the 'zip' extension) and deletes the zip.

A successful app deployment is confirmed by:

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.

In Mule 3.8.2 and later, you can deploy applications in parallel. Deploying applications in parallel reduces the startup time when you deploy a large number. The maximum number of deployment threads is set to 20 and is not configurable. To prevent deployment failure, ensure that applications are not dependent on each other because a particular start order cannot be guaranteed.

To enable parallel deployment, start Mule using the -M-Dmule.deployment.parallel option. For example:

mule -M-Dmule.deployment.parallel

All applications in the /apps directory start in parallel.

Don’t delete the application folder directly, but rather delete an app’s anchor file only:

Deleting only the app’s anchor file:

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.

Updating a Mule application at runtime can be a complex change involving class modifications, endpoint modifications (for example, changing ports, etc), as well as reconfigured flows. As a result, any application update does a graceful app shutdown under the hood and reconfigures itself. In practice, this is pretty transparent to the user and happens within seconds.

There are several ways an application can be updated:

As you see, both integrate pretty well with existing build tools, the preference for one over another really depends on established development practices only.

If you’re deploying multiple applications to the same place and those applications could share the same resources, then you can create a common domain where you can define common configurations that can then 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.

Mule runtimes run independently with the Management pane to execute integration logic and serve API requests. This architecture allows for the runtimes to be deployed strategically (on-prem and cloud) and ensures it is not a bottleneck for any communications. When/if an event occurs which causes the runtimes get disconnected from the Management pane, they continue to run as designed and execute integration and/or serve API without interruption. However, new or updated policies will not be pulled and updated until the connection is re-established.

If you want to run Mule 3 in the legacy 2.x way, edit $MULE_HOME/conf/wrapper.conf file and replace the following lines:

With:

When run in this legacy mode, none of the new application deployment features apply.

When Mule is embedded in an application server, Java application, unit test, IDE, etc and started programmatically, the deployment functionality is disabled and Mule follows the legacy application model.

If the application fails to start (for example, in a broken configuration file), Mule does not monitor the app for changes (as there technically is no application running). To update such an app, simply redeploy the app by dropping an updated archive into the apps folder.