Contact Free trial Login

Deployment Descriptor

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.

Mule’s deployment descriptor is a properties file ( 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


ClassLoader domain for this application. Typically used to share common libraries between applications and/or to allow use of different library version in applications. Maps directly to $MULE_HOME/lib/shared/<domain>. For example, stockDomain maps to $MULE_HOME/lib/shared/stockDomain.



A Mule 2.x-style comma separated list of configuration files 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. Note that the first config piece is considered to be a 'master' and is monitored for redeployment, but not others.

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


Allows explicitly disabling application hot-redeployment - configuration 'master' file will not be monitored for changes. 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


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



Configuration builder to use for parsing the application config file.


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


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

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:



An application may also contain a file in the application root (right next to the file). The 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.

Classloadling in Mule

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

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub