Documentation current as of Mule 3.0.0 (CE)
A Mule application has a structured layout under
Mule supports both packaged and exploded deployment.
Packaging a Mule App
- Create an application under
- Package your custom classes as a JAR file and put it under lib directory, e.g
- Put the configuration file in the app root and name it
- 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:
with this one:
When run in this legacy mode, none of the features described below apply.
Start Mule by specifying an app to run:
foo is a Mule app at
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.
The following describes the classloader hierarchy.
- Shared CL domains can feature different versions of the same library for different sets of applications
- Unless otherwise instructed, the default domain is used. Custom domain can be specified via the domain property in the application deployment descriptor.