Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.8)
  3. Installing and Deploying Mule
  4. Deploying Mule Runtime
  5. Mule App Deployment Model

  6. Mule Application Deployment Descriptor

Mule Application Deployment Descriptor

Mule runtime engine version 3.8 reached its End of Life on November 16, 2021. For more information, contact your Customer Success Manager to determine how to migrate to the latest Mule version.

Mule’s deployment descriptor is a properties file (mule-deploy.properties) that controls how a Mule application should be deployed. A typical application, however, would rarely need to use many of the configuration properties available in the file, relying instead on defaults.

If you’re deploying multiple applications through a Shared Resources structure, then you shouldn’t set anything in the properties files, as there might potentially be conflicts between the various apps that share a domain. Instead, you can set environment variables over the scope of the deployed app, its domain and other apps under that domain. In Studio you can create these variables through the Environment tab of the Run Configurations menu, reachable via the dropdown menu next to the Play button.

Mule checks if there is a deployment descriptor file in the application root and uses it if available (it’s optional).

Here’s the list of supported configuration properties in the deployment descriptor:

Name Description Default

domain

Domain name for this application. Typically used to share common libraries and configuration between applications. See Shared Resources

"default"

config.resources

A comma separated list of configuration file names for this application. Typical use is to support split configurations declaratively. An alternative is to have a default mule-config.xml file import extra configuration pieces. All configuration files are monitored for redeployment.

mule-config.xml from the app root is used if nothing else is specified

redeployment.enabled

Allows explicitly disabling application hot-redeployment. Dropping a new version of the application archive in the $MULE_HOME/apps will still redeploy the application. Any values other than true, yes, on are treated as false and disable the config change monitor.

Enabled by default

encoding

Default encoding, used throughout the application if none specified explicitly on, for example,. a transformer

UTF-8

config.builder

Configuration builder to use for parsing the application config file.

AutoConfigurationBuilder

scan.packages (since Mule 3.1)

The application’s classpath is no longer scanned for iBeans annotations (@Call, @Template and @IBeanGroup). The regular Mule annotations (for example, @Transformer still work). To reactivate classpath scanning, configure a comma-separated list of package names to scan for annotations at startup.

Empty by default

loader.override

Overrides default class loading. The property value is specified as a comma-separated list of classes, packages, or both. Blocking can also be specified by preceding the classes or packages in the list with a - (dash/minus sign). If a class is specified in the blocking list, its lookup is performed within the application or plugin only, and not in Mule. For further details, see Classloader Control in Mule.

Empty by default

log.configFile

The location of the log4j2.xml configuration file, that sets various parameters of the logging, such as synchronous vs asynchronous. See Logging in Mule.

MULE_HOME/conf

Two things to note:

  • Classloader domains can feature different versions of the same library for different sets of applications.

  • Unless otherwise instructed, the default domain is used. You can specify a custom domain using the domain property in the application deployment descriptor.

Below is an example of the contents of a simple deployment configuration file:

redeployment.enabled=true
encoding=UTF-8
domain=default
config.resources=sfdc-outbound-messaging-example.xml

Options

An application may also contain a mule-app.properties file in the application root (right next to the mule-deploy.properties file). The mule-app.properties file is the place to put any custom properties for the application. Mule will make them available in the registry and they can be accessed in two ways:

  • At application startup in the configuration file. Use a ${foo} placeholder (or any Mule expression which can get to the registry) to lookup a foo value.

  • In the code (for example, by implementing MuleContextAware). A registry ref is then accessible through muleContext.getRegistry(). You can then use any suitable lookup method on this instance.

Classloading in Mule

For details on classloading in Mule, including a diagram of the Mule classloading architecture, see Classloader Control in Mule.

Deployment Descriptor in a Domain

Just as in Applications, you can add a mule-deploy.properties in the src/main/domain folder of a domain project. This deployment descriptor file only supports the following properties:

Name Description Default

redeployment.enabled

Allows explicitly disabling domain hot-redeployment. Dropping a new version of the domain archive in the $MULE_HOME/apps will still redeploy the domain. Any values other than true, yes, on are treated as false and disable the config change monitor.

Enabled by default

loader.override

Overrides default class loading. The property value is specified as a comma-separated list of classes, packages, or both. Blocking can also be specified by preceding the classes or packages in the list with a - (dash/minus sign). If a class is specified in the blocking list, its lookup is performed within the domain or plugin only, and not in Mule. For further details, see Classloader Control in Mule.

Empty by default