Why Use Domain Project?
Why Use Domain Project?
This example eliminates the use of Domain Project. Whatever we can share in a Domain Project, we can achieve using a common project — or we can achieve even more.
Join the DZone community and get the full member experience.Join For Free
How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
Defining flows, subflows, or any message processors as shared resources is not supported.
To share a WMQ connector as a shared resource, you need to remove the
mule-transport-wmq-ee-.jarfile from the
$MULE_HOME/lib/mule/per-app/directory and remove all the native jars for WMQ connectivity in your application’s
$MULE_HOME/apps//lib/ directory. Place all these JARs in the
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.
Only the following connectors and related specifications can be specified as shared resources at this time:
HTTP/HTTPS (both endpoints and connectors).
TLS Context elements.
JMS Caching Connection Factory.
JBoss Transaction Manager.
Bitronix Transaction Manager.
Why Should You Use Domain Project?
It's not clear what the main purpose of this Domain Project concept is if we can't share some important common flows. For example, suppose we have some exception strategy flows that are common among various projects. As per the documentation, Domain Project will not serve our purpose.
Mule has this 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?
In this experiment, first, I will create a project with shared resources (
my-common-flows). For simplicity, I am creating the following shared resources.
One HTTP listener.
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.
This is an empty flow without any flow elements. It only contains an HTTP Listener configuration.
This configuration file contains a single flow called
Also, I have a simple property file with a simple property as shown below.
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
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,
HTTP Listener (declared in
Common exception handling (declared in
A shared property (declared in the
Here is the simple flow diagram:
The most important part in the configuration file
my-domain-test.xml is the following:
On importing the shared resources in other projects, sometimes, Anypoint Studio fails to load the resources. To solve this, just close and open the project.
The example shown above eliminates the use of Domain Project. Whatever we can share in a Domain Project, we can achieve using a common project — or we can achieve even more (sharing common flows).
Opinions expressed by DZone contributors are their own.