Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.4)
  3. Deploying
  4. Mule Deployment Model

  5. Deployment Descriptor

Deployment Descriptor

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.

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

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.

"default"

config.resources

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

redeployment.enabled

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

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

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.

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.

Classloadling in Mule

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