Practical overview of sharing global configuration using Domain Project

Last Updated on 05/05/2021 by Patryk Bandurski

In the previous article, I have described how to share common functionality encapsulated in the flows and subflows. This time I will focus on the common configurations that should be shared among our applications, especially in the context of on-prem deployment. Mule has a domain project application that can solve that. You will see how can we use this in brand new Mule version 4.

Domain project

MuleSoft applications in the default domain
MuleSoft applications in the default domain

Each application that you create has a relationship with the default domain project. This domain does not share anything with your application. It just exists! Like in the diagram above. We have three deployed applications that were developed separately, but still, they have the default domain attached. 

When you create your very own domain project, you may choose which applications should use it. As you can see below, we have an application with a default domain and two other applications related to other non-default (myproject) domain in our environment.

Two MuleSoft applications using custom myproject domain
Two MuleSoft applications using custom myproject domain

So what exactly does domain project do?

Port binding error problem

I have two applications that would listen on port 8081 but on different paths. When I develop two applications and test them, everything should work as designed. The problem starts when we would try to deploy them on the application server. We will receive the port binding error.

Only one application listening on the given port is allowed. Completely normal and obvious situation. But would that mean that we need to give different ports for all our services?

The answer is NO.

Solution

Using domain projects we can share global configuration and properties. In our case, all we need to do is to create an HTTP Listener configuration with our specif port. Then in each application related to our new domain, can choose this configuration for its HTTP Listener. 

When we bind our application to a custom domain we automatically get not only shared common configuration and properties but also dependent libraries. Of course, we can have our own common mule library that we attach only to specif applications. But we may, as well, attach it to the domain project. As a result, all applications within this domain would gain this dependency.

Custom domain project sharing global configuration, properties and modules like HTTP, Munit and custom Common Module
Custom domain project sharing global configuration, properties and modules like HTTP, Munit and custom Common Module

How to create Mule Domain Project?

So let us begin with an empty domain.

  1. In Anypoint Studio choose New > Mule Domain Project 
  2. Name the project and choose the runtime
  3. Confirm clicking the Finish button

On the screenshot, you can see an empty Mule Domain Project. I like that Anypoint Studio uses different color next to the project name. I can quickly localize the domain project in Project Explorer.

Newly created mydomain Domain Project
Newly created mydomain Domain Project

Dependency to Mule module

We may choose to use same version of mule modules like HTTP or JMS. So let’s see how to do it.

  1. Open mule-domain-config.xml file
  2. Click the Manage Modules button on the right-hand side
  3. In the Properties window click from Featured Modules or from Exchange
  4. Then search for specific modules like HTTP, JMS
  5. Click Apply and Close
Adding HTTP and JMS MuleSoft Modules to Mule Domain Project
Adding HTTP and JMS MuleSoft Modules to Mule Domain Project

Warning

Remember to remove duplicate dependencies from your applications. For example, the HTTP module is added by default. If you decide to include it in the domain, make sure that it won’t appear in the application. Otherwise, you receive a warning in the pom.xml file, similar to the one below
There is a multiple definition both in application and linked domain (mydomain) of module org.mule.connectors:mule-http-connector:1.5.23. Right-click for a quick fix.

After the dependencies are collected, you should see them in your project structure in Package Explorer.

Properties

Our projects may share the same configuration properties. Instead of duplicating them, we can embed them into Mule Domain Project.

We do it, like in the standard Mule project. First, create a file with extension yaml. Then may use properties defined in that file in both the global configuration in the domain project and Mule applications attached to that domain.

Sample yaml file:

http:
  port: "8081"
app:
  origin: "Ambassador Patryk's Blog"

Global configuration

The logic is the same as with the standard Mule application. When you open mule-domain-config.xml file you will see two tabs instead of three. 

Domain global configuration
Domain global configuration

The reason for this is simple, you are not allowed to define flow and subflows in the domain project. You can do this using the separate library, but that I have already described.

Summary

Domain project has always used either default or a custom one. In order to create that project, you use the separate option in the menu of Anypoint Studio. This feature allows sharing of global configuration and properties. It is a good place to share other dependencies as well for example mule modules, custom java libraries, and our own custom library with reusable flows.

In the next article I describe how to include given application into a custom domain.

Practical overview of sharing global configuration using Domain Project

Leave a Reply

Your email address will not be published.

Scroll to top