You are viewing an older version of this section. Click here to navigate to the latest version.

Deployment Descriptor

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.

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.


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.