DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Using DuckDB With CockroachDB
  • How To Become a 10x Dev: An Essential Guide
  • Enriching Kafka Applications With Contextual Data
  • Develop Hands-Free Weather Alerts To Ensure Safe Backpacking

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.

Anupam Gogoi user avatar by
Anupam Gogoi
·
Jan. 10, 17 · Opinion
Like (6)
Save
Tweet
Share
8.67K Views

Join the DZone community and get the full member experience.

Join For Free

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

  • 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-.jar file 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 $MULE_HOME/domains//lib/ folder instead.

  • 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).

    • VM.

    • TLS Context elements.

    • JMS.

    • JMS Caching Connection Factory.

    • Database.

    • WMQ.

    • 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.

My Argument

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?

Experiment

In this experiment, first, I will create a project with shared resources (my-common-flows). For 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

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.

Exception Handling flow

init-DEV.properties

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

Init properties

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:
pom configuration

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:

my-domain-test

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:

Using shared resources

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

Importing the flows as Spring Bean.

Troubleshooting

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.

Conclusion

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).

Flow (web browser)

Opinions expressed by DZone contributors are their own.

Trending

  • Using DuckDB With CockroachDB
  • How To Become a 10x Dev: An Essential Guide
  • Enriching Kafka Applications With Contextual Data
  • Develop Hands-Free Weather Alerts To Ensure Safe Backpacking

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: