Sharing Global Configuration

Sharing Global Configuration

Take a look at common configuration that should be shared among applications and explore a domain project.

Free Resource

In my previous article , I described how to share common functionality encapsulated in flows and subflows. This time, I will focus on common configuration that should be shared among our applications. Mule has offered domainapplication that can solve that. You will see how can we use this in bran new Mule version 4.

Domain Project

Each application that you will create has a relationship with defaultdomain 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 have the default domain attached.

When you create your very own domainproject, you may choose which applications should use it. As you can see below, in our environment, we can have applications that have a  default domain but also other applications related to other non-default domain applications.

So what exactly does domain project do?

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 design. The problem starts when we would try to deploy them on the application server. We will receive port binding error.

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

The answer is no .

Solution

Using domain project, we may share global configuration and properties. In our case, all we need to do is create HTTP Listener configuration with our specific port. Then, in each application related to our new domain, we may choose this configuration item.

When we bind our application to the 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 like in the diagram above. But we may as well attach it to the domain project. As a result, all applications within this domain would gain this dependency.

How to Create a Domain

Let us begin with an empty domain.

1. In Anypoint Studio choose New > Mule Domain Project
2. Name the project and choose runtime

Dependency to Mule Module

We may choose to use the 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 Manage Modules button on right hand side
3. In Properties window click Add Module
4. Then search for specific modules like HTTP, JMS
5. Click Apply and Close

Warning

Remember to remove duplicate dependencies from your applications if applicable. For example, HTTPmodule is added by default. If you decide to include it in domain, make sure that it won't appear in application. Otherwise, your application will not start.

As you can see, dependencies have been download and attached to the project.

Properties

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

We do it, like in the standard Mule project. We create a file with extension yaml and place their properties. We may use them in the global configuration in domain project, but also in Mule applications within that domain.

Sample yaml file:

http: port: "8091" profit: info: "ProfIT domain application"

Global Configuration

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

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

Summary

Domainproject is always either a default or a custom one. In order to create that project, you use a separate option in the menu of Anypoint Studio. This feature allows the 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 will describe how to include a given application into a custom domain.