Reading Time: 4 minutes

We often see the need to a component configuration between 2 applications deployed to . For example, let's say you have two Mule applications deployed in your Mule server. The first one, called  AppA, gets information from Salesforce and stores it in a database. The second AppB modifies your Salesforce campaign information. Both applications share the same Salesforce credentials, so what happens if those credentials change? (for example, because you are switching from the SFDC sandbox to the live instance) You need to modify both applications because you have your Salesforce cloud connector configuration duplicated.

Splitting Configuration Files

latest report
Learn why we are the Leaders in management and iPaaS

It is actually quite simple to extend a configuration from a parent mule-config file. You just need to follow these steps:

1) Create the parent mule config file (for example, salesforce-parent-config.xml), which in our case, would be something like this:

Could not embed GitHub Gist 1666378: Not Found

and put it into the MULE_HOME/apps directory.

2) Next, create your child application (for example, AppB) using the beans defined in your parent config as if they were part of the child configuration:

Could not embed GitHub Gist 1666431: Not Found

Be sure that in your MULE_HOME/apps/AppB directory you have a file called with the following configuration:

Could not embed GitHub Gist 1666479: Not Found

Note, see the Mule Deployment Descriptor documentation for more information about this.

This will tell Mule that it first has to read the ./apps/salesforce-parent-config.xml file and then the mule-config.xml file of your AppB, so that the configuration defined in the parent file is usable from AppB. The good thing is that if salesforce-parent-config.xml file changes, then all the child applications (AppA, AppB) will be automatically redeployed in Mule, so you don't need to change or stop your applications.

Can Apps Share Libraries Too? 

Of course! You just need to drop the shared jar files into the MULE_HOME/lib/user directory and those jars will be shared by all the applications deployed in Mule.  Mule also supports the notion of application domains that allows applications to be grouped and jars shared between apps in the same domain.  See the documentation about class loading in Mule for more information.