Introduction
This page describes how to start and stop Mule in various ways.
MULE_HOME and MULE_BASE
Since version 1.3.3, Mule supports multiple installations on the same machine in the way that Apache Tomcat does. A normal Mule installation is considered MULE_HOME, and it is normally set in your environment. However, many users have the situation where they want a single base installation of Mule and allow multiple users to have their own individual Mule instance with separate logs, configuration and jar directories. For this reason, we allow you to set up secondary Mule instances that run off the base installation.
Consider the scenario in which you have installed Mule as a "root" user on a Unix box, in the /opt directory. Here, the MULE_HOME environment variable will be something like /opt/mule-1.3.3. Now, you want to create a local instance of Mule for user "joe" in Joe's home directory /home/joe.
For the sake of efficency you can use the $MULE_HOME/bin/util/setup_local_instance.sh script to create this local instance. What this script does, but which you can do yourself, is to create a $MULE_BASE directory structure that contains the following:
- ./bin - Contains startup scripts copied from $MULE_HOME/bin
- ./conf - Contains local configuration files, copied from $MULE_HOME/conf
- ./examples - Contains examples, if desired
- ./lib/user - Contains user jars
- ./logs - Contains local logs
User joe, then, will define two environment variable in this example: MULE_HOME, which will point to the base Mule installation in /opt, and MULE_BASE, which will point to the local installation under /home/joe. When Joe starts Mule, Mule will first load any jars in MULE_BASE/lib/user, and then will load the jars under MULE_HOME/lib. This allows Joe to place new jars (say for testing) in MULE_BASE/lib/user and override those in MULE_HOME/lib/user, without causing any problems for the other users. Additionally, Joe can edit the startup scripts and configuration files as needed. Joe's Mule logs will also be kept in the MULE_BASE directory structure.
Note that if you have both MULE_HOME and MULE_BASE set, and run Mule for the first time (see [MULE:Running Mule for the first Time]), the following will occur:
- a copy of the license acceptance jar will be placed in MULE_BASE/lib/user
- any third party jars downloaded by Mule will be placed in MULE_BASE/lib/user
 | From 1.4.4 onwards the above changed to:
- a copy of the license acceptance jar will be placed in MULE_HOME/lib/user
- any third party jars downloaded by Mule will be placed in MULE_HOME/lib/user
When providing Mule in a multi-install make sure to run it at least once during the initial install so acceptance and third party libs are properly configured and available for users using MULE_BASE subsequently in their own environment. |
Java Service Wrapper
Mule uses the Java Service Wrapper (http://wrapper.tanukisoftware.org) to control the JVM from your native OS. The wrapper provides many advanced options and features which you can read about on the Wrapper website. In brief, the Java Service Wrapper can install (or remove) Mule as a Windows NT Service or Unix Daemon. The Wrapper can handle system signals and provides better interaction between the JVM and the underlying OS.
Starting Mule from a Script
To start mule, it is easiest to use the 'mule' and 'mule.bat' scripts in the distribution bin directory. These scripts invoke the Java Service Wrapper.
If you want to simply run Mule, without bothering with running it as a service or daemon, just type
mule -config <your-config-file.xml>
If you don't specify the "-config" option, Mule will look for a file called mule-config.xml. (There is no such file in the stock distribution). For more examples of the syntax above, refer to the scripts in the examples directory of your distribution.
Running Mule as a Service
If you want to install Mule as a Windows NT Service or Unix daemon, type
Likewise, to remove Mule from your services or daemons, type:
Once you have Mule installed, you can then invoke the service exactly as you did before, but with an additional parameter:
mule start|restart|stop -config <your-config-file.xml>
The "start"/"restart"/"stop" arguments tell the Mule service to start, restart or stop, respectively.
Passing Additional Arguments to the JVM
The Wrapper provides several properties you can set as described here. If you want to pass additional arguments to the JVM that will run Mule, you can add wrapper.java.additional.n entries to the wrapper.conf file in the /conf directory under the Mule installation directory, or you can pass the arguments at the command line by adding the -M switch.
For example, to set Mule's encoding, you could add wrapper.java.additional.1=-Dmule.encoding=ISO-8859-1 to the Wrapper configuration file, or you could add -M-Dmule.encoding=ISO-8859-1 to the Mule script at the command line. Note that if you add wrapper.java.additional.n entries to the configuration file, you must change each instance of n to a consecutive number, or Java will not parse the properties correctly.
Starting Mule Directly
To start a mule server from a script or from your IDE without using the Java Service Wrapper, you can use the org.mule.MuleServer class. This accepts a couple of parameters.
org.mule.MuleServer -config mule-config.xml or
org.mule.MuleServer -builder <fully qualified classname> -config appContext.xml
- -config param specifies one or more config files to use. If this argument is ommitted the default 'mule-config.xml' will be used.
- -builder param is a fully qualified classname of the config builder to use. If this is not set the default org.mule.config.builders.MuleXmlConfigurationBuilder is used.
The eaisest way to set the classpath is to include all jars in the ./lib/mule and ./lib/opt directories of the distribution. You can have a look at the dependency report for the server and each of the modules to see exactly which jars are required for a particular module.
You can also start a mule server from your code by using one of -
MuleServer server = new MuleServer("mule-config1.xml,mule-config2.xml");
server.start(true);
Often it will not be necessary to start the server like this. If you want to embed Mule in an application or a webapp see -
Stopping Mule
For both Windows and Unix installations, terminate Mule by typing "CTRL-C" in the command shell or console in which it is running.
If Mule was started in the background on Unix, the process can be killed, for example:
ps -ef|grep mule
kill PID
Where "PID" is the process id of the Mule process.
Backgrounding a Linux\Unix process
If you run Mule from a shell you should run it as a background process if you want it to continue running after you close the shell. To do this you can use nohup i.e.
or by backgrounding the process using disown
This page
Other pages
Account
New