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

  5. Application Server Based Hot Deployment

Deployment Model for Mule in Application Servers

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

If you are running Mule deployed in an Application Server, you have the option to configure Mule as a service of the container, which allows you to maintain a single instance of Mule but update your configuration files and/or transformers, filters, or component implementations without restarting Mule. When you hot deploy a Mule application, only that application will stop/start, and any other Mule applications that are deployed will continue to run as before. This is the same benefit you get when you run Mule standalone.

Deployment is currently tested and supported with Mule ESB 3.3.1 or later and the following application servers:

  • Jetty 8

  • Tomcat 7

  • Weblogic 10

  • JBoss 6.1

  • JBoss 7

  • Websphere 7

  • Websphere 8

  • Weblogic 11g

  • Weblogic 12c

How it Works

A Mule application is one or more configuration files packaged up with any dependencies that are not already provided by Mule. In a deployment scenario, each Mule application shares a single Mule instance running in an application server or web container. To hot deploy Mule applications, you do the following:

  • Configure Mule to run as a service in the container (see instructions below)

  • Package your Mule applications as WAR files so that you can deploy them as web applications

When you deploy the WAR file, Mule reads the Mule configuration file and creates and starts all the required objects just as when running Mule standalone. When you undeploy a Mule application, only the objects created and started for that Mule application are stopped and disposed of without affecting any other applications sharing the same Mule instance. In this way, multiple Mule applications can be deployed, undeployed, and redeployed independently with no downtime for any other services.

Two of the key advantages of using a single shared Mule instance running as a container server are:

  • A greatly reduced memory footprint over using multiple Mule instances.

  • The ability to share objects across applications. For example, you could have a single webapp that defines the connectors, filters, and transformers that are then used by the other webapps.

    Note: If you share objects across applications, be sure to first deploy the webapp that creates the shared objects, and then deploy the remaining webapps that use those objects.

Below is a table listing the key differences in the two supported webapp deployment models for Mule ESB:

Self-Contained Webapp Container Service

Memory footprint

Larger

Smaller

Application isolation

More

Less

Shared resource management

None

Possible

Hot deployment

Entire Mule Application is deployed/undeployed

Only resources required for the application are deployed/undeployed

Preparing the Configuration File

When defining the scope of your applications and their configurations, keep the following points in mind:

  • Each Mule application uses an instance of Mule that is already started. Therefore, your application cannot modify anything in the <configuration> element, including attributes and child elements, which are required to be configured before Mule startup. If you need to modify these settings, you must modify them on the Mule instance and restart it.

  • If you don’t explicitly define the connector that should be used by an endpoint, and another web application that is already deployed defines a connector that supports the same protocol, that existing connector defined will be used.

Deploying Mule as a Service

To deploy Mule as a service to Tomcat or Tcat Server, see Deploying Mule as a Service to Tomcat.

Packaging the Mule Application

Each Mule application you set up for hot deployment consists of one or more configuration files plus supporting custom classes, all packaged as a standard web application (WAR deployment archive file). You can create the WAR using your favorite IDE or build tool as you would create any standard web application.

Note: Wile these instructions describe WAR packaging, you could also deploy to JEE environments as an EAR.

To enable Mule to find and load your configuration, you must include a web.xml file that points to your configuration files and to the deployable listener, as shown below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>

    <display-name>MuleEchoExample</display-name>
    <description>Mule Echo Example</description>

    <context-param>
        <param-name>org.mule.config</param-name>
        <param-value>echo-cxf-config.xml</param-value>
    </context-param>

    <!--
        To use a Mule XML configuration file use this context listener
    -->
    <listener>
        <listener-class>org.mule.config.builders.DeployableMuleXmlContextListener</listener-class>
    </listener>

</web-app>

Deploying the Mule Application

You deploy your Mule application WAR file in exactly the same way you deploy any web application on the application server or web container you are using. That is, you can use a web administration console, command-line deployment tool, Maven, or your IDE. For example, if you are deploying to Tomcat, you simply copy your WAR to the Tomcat webapps directory or use the Tcat console to upload and deploy it to your server. For more information, see the documentation for your application server or web container.

If your Mule applications share objects, be sure to first deploy the application that creates those objects, and then deploy the applications that use them.