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 classloading architecture meets most classloading needs, there are times when you might need to override the default classloading scheme. For example, suppose an application requires a third-party library that is bundled with it. This might conflict with a library version that the domain 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 enables you to override default classloading.

The classloader hierarchy for the different artifacts consists of:

When a Mule EE server contains Mule Plugins, the classloading model is a bit different than 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 grain classloading. 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 class loader filter is used. Then the classloader used in the Mule Application is a Composite ClassLoader that contains a list of classloaders. The first classloader in that list is a Mule Application classloader as the one described before, and the following elements are the classloaders filters for each installed Mule Plugin.