I wrote about how you can have multiple models in a Mule application and how this is a convenient way to group services based on, say, exception handling. What if the models are in different configuration files?
This is a common development technique. Imagine having two developers both working on a Mule application but working on separate parts of the flow. Rather than have them work on the same configuration file (and have to worry about conflict resolution and version control) you could get them to work on separate configuration files in the first place. After all, you can load up Mule with multiple configuration files, right?
The flaw in this approach is that now that there are two configuration files, which one should contain the exception strategy for this model? Or should I declare it twice, once per config file? Or should I split developer tasks based on exception strategies too?
The answer, thankfully, is simple. Developer A should be the one with the exception strategy in his configuration file. Developer B should merely make sure that his or her model is declared as follows:
The inherit attribute tells Mule that the exception strategy should be inherited from the previous declaration. This will only work if both models have the same name as otherwise, Mule will not know what to inherit from.
Also note that this is something that will be used when Mule is initialising and has nothing to do with Java inheritance. On the positive side, you can inherit any model related items including the entry-point-resolver.