Application Deployment

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.

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

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.

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.

Where first and second are both Mule application folders in $MULE_HOME/apps/.

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.

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.

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:

As you see, both integrate 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 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.

If you want to run Mule 3 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 application fails to start, such as when a broken configuration file is provided, Mule does not monitor the app for changes (as there is no application running). To update such an app, simply redeploy the app by dropping an updated archive into the apps folder.