Shared Resources

You can configure the domain project that you just created in the previous step by defining shared resources in the the mule-domain-config.xml file. You can define multiple resources in this configuration file. In Anypoint Studio, there are two different views for editing this file. The source view should be the most familiar for those used to the XML editor in regular Studio Mule projects:

Include, at minimum, the namespace and XML schema location for the domain, as shown below. Be sure to use the version, Community or Enterprise, that matches the resource that you are creating. VM, WMQ, and the Bitronix Transaction Manager require the Enterprise version.

Community

Enterprise

Add additional namespaces and schema locations for each resource that you want to share. See the example definitions for each supported shared resource below for full namespace definitions required for each. Note that the examples are separated into separate XML configurations for clarity, but you can define multiple shared resources in a single mule-domain project.

In Anypoint Studio, to associate an existing application with a domain, edit the mule-project.xml file located at root level in the project. In the graphical view of this file, you will see a Domain field, which by default is set to default, this value gives each project its independent domain. Change this value, the dropdown list on this field will display all of the domains you’ve created in the current workspace.

Note that when picking a domain, the Server Runtime of your project automatically becomes that of the domain, as these must always match.

In the following example mule-domain-config.xml, an HTTP connector is defined as a shared resource.

Any Mule application associated with the domain can make use of the shared resource by referencing it within the configuration, just as you would reference a resource within the project itself. In the example below, the HTTP listener connector references the shared resource named HTTP_Listener_Configuration.

In Studio’s visual editor, you can simply pick the shared resource out of the dropdown list in the Connector Configuration field of the connector’s properties editor:

In Anypoint Studio, when you deploy an application that is associated to a domain, by default Studio will deploy both the application and the domain together. Also, when deploying a domain project, by default Studio will deploy every application associated to it as well. You can change these default behaviors by changing the Run Configuration for the domain, you can in fact make any set of applications in your workspace be deployed together, even if they don’t share the same domain.

To set this in Studio, open the dropdown menu next to the play button and select Run Configurations.

Then pick the General tab, and tick or untick the boxes next to the projects that you want to always deploy together with the application that is currently selected on the navigation menu to the right.

The steps below describe how to deploy your domain project and the applications outside Studio, to Standalone Mule

When Mule starts, it first deploys any domains found in the MULE_HOME/domains folder, then it deploys the applications in the MULE_HOME/apps folder, so that all domains are fully started before the applications start.

You also have the option of bundling the applications associated with a domain in your domain folder, then deploying the entire folder as a bundled unit. To do this, include an apps folder in your domain folder structure and place the zip files of your applications there.

The deployment behavior is the same as deploying a domain and apps separately: Mule will first deploy the domain itself, then the applications. Deploying domain bundles simplifies the deployment mechanism for teams by removing the manual step of deploying applications separately.

Sharing an HTTP connector within a domain allows you to reuse the same port within all the applications that belong to the domain.

Sharing an HTTPS connector within a domain allows you to reuse the same port within all the applications that belong to the domain.

Enterprise

Sharing a VM connector allows multiple Mule applications within the same domain to communicate through VM queues. Defining a VM connector as a shared resource is a best practice for consuming services provided by other Mule applications within the same container.

Sharing a JMS connector creates a common connection to the broker between multiple applications, minimizing the number of client connections to the broker.

Mule provides a caching connection factory for JMS connections to improve JMS resource utilization.

Sharing a db configuration creates a common connection to a database between multiple applications, minimizing the number of client connections to the database.

Enterprise

Sharing a WMQ connector creates a common connection to the broker between multiple applications, minimizing the number of client connections to the broker.

To share a WMQ connector as a shared resource, you need to remove the mule-transport-wmq-ee-<mule-version>.jar from $MULE_HOME/lib/mule/per-app/ folder and remove native wmq jars from your application’s $MULE_HOME/apps/<my-app>/lib/ directory. Place all these jars in the $MULE_HOME/domains/<my-domain>/lib/ folder instead.

For example:

When you define JMS connectors and db configurations as shared resources in your domain, you may have to use XA transactions in your applications. In this case, you must define the XA transaction manager in your domain configuration as well.

Enterprise

When you define JMS connectors and db configurations as shared resources in your domain, you may have to use XA transactions in your applications. In this case, you must define the XA transaction manager in your domain configuration as well.

The Bitronix module integration also provides a JMS connection factory pool and a datasource pool to be used when using a datasource with XA transactions. You can define either or both of them as shared resources.