Documentation current as of Mule 3.0.0 (CE)

Application structure

A Mule application has a structured layout under $MULE_HOME/apps.

Mule supports both packaged and exploded deployment.

/
 \- lib                 // application-specific jars
 |- mule-config.xml     // Main Mule configuration file, also monitored for changes

Packaging a Mule App

1. Create an application under $MULE_HOME/apps. E.g. $MULE_HOME/apps/foo.
2. Package your custom classes as a JAR file and put it under lib directory, e.g $MULE_HOME/apps/foo/lib/my-custom-classes.jar
3. Put the configuration file in the app root and name it mule-config.xml.
4. After making a change to your application, simply update the timestamp on the configuration file using the touch command (if available on your operating system) or by saving your configuration file (e.g., add and delete a character, and then save).

Disabling the Mule Container Mode

If you want to run Mule 3 the legacy 2.x way, edit $MULE_HOME/conf/wrapper.conf file and replace the following line:

# Java Main class
wrapper.java.mainclass=org.mule.module.reboot.MuleContainerBootstrap

with this one:

# Java Main class
wrapper.java.mainclass=org.mule.module.boot.MuleBootstrap

When run in this legacy mode, none of the features described below apply.

Start Mule by specifying an app to run:

mule -app foo

where foo is a Mule app at $MULE_HOME/apps/foo.

From this moment, Mule checks every three seconds for the $MULE_HOME/apps/foo/mule-config.xml updates. One can update the application jar contents and touch/modify this file to have Mule reload the config and class modifications.

Classloader layout

The following describes the classloader hierarchy.

1. Shared CL domains can feature different versions of the same library for different sets of applications
2. Unless otherwise instructed, the default domain is used. Custom domain can be specified via the domain property in the application deployment descriptor.