Mule Configuration Inheritance

motif

We often see the need to reuse a component between 2 applications deployed to . For example, let’s say you have two applications deployed in your 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

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:

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:

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

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.


We'd love to hear your opinion on this post


3 Responses to “Mule Configuration Inheritance”

  1. Hey, thanks for the info. Can you next reduce the need for horizontal scrolling. It can be a pain. Better if I can read the XML without any scrolling at all, so long as its practical.

  2. hi thanks for posting…

    as you said i have created two projects projectA,projectB

    in Project A i have configured jms connector details and file connector details…
    i would like to share jms connector details which has been configured in Project A to Project B…

    i have updated apps/deploy.proerties -config resources properties with refferring to Project A..but i am not able to share those details in ProjectB…

    Resource is out of sync with the file system: ‘/sharingtest2/src/main/app/mule-deploy.properties’.

    • hello, it’s nice to see people trying this out!.

      There are so things in to pay attention on this topic, the projectA mule configurate (the XML) can be anywhere for example in the MULE_HOME/apps, the only thing that you need to put in there is the configuration you want to share, not the libs, not resources, just the mule-config.xml (or whatever you named it).

      The mule-deploy.properties has to be named this way and has to be in the MULE_HOME/apps/ProjectB directory (check that you have this in that exact root, maybe this is what is happening to you, it is not in the MULE_HOME/apps/ProjectB).

      finally, the mule-deploy.properties must be something like this: config.resources=../projectA-parent-config.xml,mule-config.xml

      I don’t get what you meant with “Resource is out of sync with the file system: ‘/sharingtest2/src/main/app/mule-deploy.properties’”

      hope this helps