Mule has the concept of a Domain Project to share common resources. However, per the documentation, there are some limitations when using a Domain Project to share resources. Here are the main limitations as per the documentation:

1. Defining flows, subflows, or any message processors as shared resources is not supported.

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

3. Adding properties in the configuration files of applications that use shared resources can result in issues, as these properties are shared with other apps in the domain and there may be conflicts. You can instead set environment variables.

4. The following connectors and related specifications can be specified as shared resources at this time:

   • HTTP/HTTPS (both endpoints and connectors).

   • VM.

   • TLS Context elements.

   • JMS.

   • JMS Caching Connection Factory.

   • Database.

   • WMQ.

   • JBoss Transaction Manager.

   • Bitronix Transaction Manager.

Why Should You Use Domain Project?

The main power of Domain project really comes into play at the time of Deployment (Mule Runtime). Along with sharing common configurations among the projects using the Domain project, it can also be used to share common libraries among the projects. (I will discuss how to tweak with Domain Project to reduce the Mule deployment time in another article). In general, though, sharing common flows like exception handling, etc. is not a great idea in Domain Project.

My Argument

Mule has an out-of-the-box concept where every flow is treated as a Spring Bean.

So, my argument is: why don't we create a project and put all the common flows, resources (HTTP, VM, etc.), and connections and export this as JAR and use it as a dependency in other projects and load the flows as Spring Beans?

Experiment

In this experiment, I will first create a project with shared resources (my-common-flows). For the sake of simplicity, I am creating the following shared resources.

1. One HTTP listener.

2. Common exception handling strategy.

Most importantly, I am exporting this project as a JAR file instead of the conventional ZIP. Here is the source code of the project. In this project, I have two flows only:

connections.xml

This is an empty flow without any flow elements. It only contains an HTTP Listener configuration.

my-common-flows.xml

This configuration file contains a single flow called common-exception-handling.

init-DEV.properties

Also, I have a simple property file with a simple property as shown below.

pom.xml

Most importantly, I am not using the ZIP packaging format in the pom.xml file. Instead, I am packaging it as a JAR. Please check this part of the pom.xml file as shown below:

Using Common Resources

Now we are going to use this common resource in a project named my-domain-test. The source code is available here. So, first of all, we will modify the pom.xml file of the project and insert dependency of the common resource project we have created above. Here is a part of the pom.xml:

That’s it. Now we can use the shared resources. Here in this project we have a simple flow where I am using the following shared resources,

1. HTTP Listener (declared in connections.xml of the my-common-flows project).

2. Common exception handling (declared in my-common-flows.xml of the my-common-flows project).

3. A shared property (declared in the init-DEV.properties of the my-common-flows project).

Here is the simple flow diagram:

The most important part in the configuration file my-domain-test.xml is the following:

Troubleshooting

When importing the shared resources in other projects, Anypoint Studio occasionally fails to load the resources. To solve this, just close and open the project.

Conclusion

The above discussion shows how easily the common flows and configurations can be shared using Common Project. Thus we can eliminate the limitations of Domain project when it comes to sharing common flows and configurations. However, for sharing common libraries among various projects in Deployment scenarios (Mule Runtime)  under the same domain , Domian Project plays a great role. 

Let's get in touch about how Avenue Code can guide you as the preferred systems integrator for MuleSoft Anypoint Platform!