Classloader Control in Mule

Mule defines a hierarchy of classloaders to find and load classes for execution. This hierarchy uses a "parent first" model by default, this means that each classloader attempts to load a class using its parent classloader before attempting to do it itself.

Although this class loading architecture meets most class loading needs, there are times when you might need to override the default class loading scheme. For example, suppose an application requires a third-party library that is bundled with it. This might conflict with a library version that any parent classloader would load (that is, a version of the library already bundled with Mule). How do you ensure that the required version of the library is used with the application? To address requirements such as these, Mule supports fine-grained class loading control that lets you override default class loading.

The classloader hierarchy for the different artifacts consists of:

When a Mule EE server contains Mule Plugins, the class loading model is a bit different from the previously described hierarchy. The main difference is that applications can access resources exported by Mule Plugins.

To support that scenario, each Mule plugin has a classloader supporting fine- grained class loading. These classloaders are created using the Mule system classloader as the parent. Mule Plugins can contain many classes, libraries and resources, but only some of them should be accessed from the application. To avoid exporting unnecessary resources from a Mule plugin, a classloader filter is configured for the plugin, and then as the Mule Application’s classloader, a Composite ClassLoader is configured that contains a list of classloaders. The first classloader in that list of classloaders is a Mule Application classloader, such as the one described earlier, and the elements that follow it are the classloader filters for each installed Mule Plugin.